<div dir="ltr"><div dir="ltr">On Thu, May 16, 2024 at 7:10 AM Martin via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If a compiler adds a DW_TAG_subprogram for a routine from a different <br>
compilation unit ...<br>
Maybe because<br>
- the other CU has no debug info<br>
- The compiler does not support referencing cross CU<br></blockquote><div><br>None that I can think of.<br><br>This happens in some cases in more normal situations - such as concrete definitions of inline functions - you'd have multiple CUs with subprograms that describe the same function definition, with low/high pc.<br><br>In the "doesn't support cross-CU references" - I'd expect in that case to only produce a subprogram declaration (eg: if you need a call_site for a call to a function defined in another object file). In the first case (other CU has no debug info) yeah, theoretically, I guess, maybe you'd want to produce debug info for the thing you didn't define.<br><br>But generally my understanding is producers don't do that.<br><br>Oh, one reason that is tricky to do it - adding a reference to a symbol not defined in the current object: It'd harm linker garbage collection and might cause linker failures that shouldn't occur.<br><br>LLVM has this problem with C++ templates with pointer non-type template parameters. GCC doesn't provide any location for these parameters (just a name), but Clang/LLVM produces a location that describes the pointer value. Problem is - it's possible to link a program (not 100% sure that's valid C++ or a "ill formed no diagnostic required" situation) without a definition of the global being pointed to - but if the DWARF references the global, it'll cause a link failure.<br><br>Even if it wasn't a case of the global being undefined - but if it's only referenced by the DWARF, then without DWARF the object defining the global may not be linked in (and the side effects of any global ctors in that object would not be run) but turning on debug info could change the program behavior by causing that object file to be linked in (then linking in things it references, etc) and causing any newly linked global ctors/dtors to run which weren't in the absence of DWARF.<br><br>If you wanted to avoid these problems, you'd probably need some kind of relocation (maybe a weak reference?) to use in the DWARF to ensure it doesn't change linker semantics.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Would there be any reason why the compiler would not be allowed to <br>
include a  DW_AT_low_pc  for that routine (if the compiler has the address)?<br>
<br>
In the concrete example the compiler in question (on some platforms, due <br>
to afaik linker restrictions) repeats any structure definitions from <br>
other CU, if they are needed as base classes for inheritance). But that <br>
is just background on why (afaik) this situation exists.<br>
<br>
The only such reason that I can find (if I didn't miss any) is in <br>
chapter 3.3.3 on "subroutine declaration". The complier in question does <br>
not add a DW_AT_declaration though.<br>
<br>
 > 3.3.3 Subroutine and Entry Point Locations<br>
 > ...<br>
 > A subroutine entry representing a subroutine declaration that is not <br>
also a definition does not have code address or range attributes.<br>
<br>
<br>
If such a "repeated" subroutine would somehow fall into that category, <br>
how could the routines address be communicated to the debugger?<br>
<br>
-- <br>
Dwarf-discuss mailing list<br>
<a href="mailto:Dwarf-discuss@lists.dwarfstd.org" target="_blank">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote></div></div>