[Dwarf-discuss] Question on DW_AT_low_pc for "repeated" DW_TAG_subprogram

[David Blaikie]

On Thu, May 16, 2024 at 7:10 AM Martin via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> If a compiler adds a DW_TAG_subprogram for a routine from a different
> compilation unit ...
> Maybe because
> - the other CU has no debug info
> - The compiler does not support referencing cross CU
>

None that I can think of.

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.

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.

But generally my understanding is producers don't do that.

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.

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.

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.

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.


>
> Would there be any reason why the compiler would not be allowed to
> include a  DW_AT_low_pc  for that routine (if the compiler has the
> address)?
>
> In the concrete example the compiler in question (on some platforms, due
> to afaik linker restrictions) repeats any structure definitions from
> other CU, if they are needed as base classes for inheritance). But that
> is just background on why (afaik) this situation exists.
>
> The only such reason that I can find (if I didn't miss any) is in
> chapter 3.3.3 on "subroutine declaration". The complier in question does
> not add a DW_AT_declaration though.
>
>  > 3.3.3 Subroutine and Entry Point Locations
>  > ...
>  > A subroutine entry representing a subroutine declaration that is not
> also a definition does not have code address or range attributes.
>
>
> If such a "repeated" subroutine would somehow fall into that category,
> how could the routines address be communicated to the debugger?
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240516/338c2c53/attachment.htm>