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

[Martin via Dwarf-discuss]

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

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

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

[David Blaikie via Dwarf-discuss]

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
>
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

[Dwarf-discuss] strx use in debug_line table

[Mark Wielaard via Dwarf-discuss]

Hi,

Section 6.2.4.1 Standard Content Descriptions under 1. DW_LNCT_path has
the following description on using DW_FORM_strx forms:

   In a .debug_line.dwo section, the forms DW_FORM_strx, DW_FORM_strx1,
   DW_FORM_strx2, DW_FORM_strx3 and DW_FORM_strx4 may also be used.
   These refer into the .debug_str_offsets.dwo section (and indirectly
   also the .debug_str.dwo section) because no
   .debug_line_str_offsets.dwo or .debug_line_str.dwo sections exist or
   are defined for use in split objects.
   
This confuses me a little, it is as if the strx forms are only allowed
when generating split dwarf. But that doesn't seem to be the intent,
because under 6.2.4.2 Vendor-defined Content Descriptions all DW_FORM_strx
variants are listed without special exceptions.

So I assume the description under DW_LNCT_path is just to explain that
there isn't a .debug_line_str_offsets section that the DW_FORM_strx
forms can refer to. And that DW_FORM_strx forms are resolved as normal
and can be used in both .debug_line and .debug_line.dwo content
descriptions.

This leaves the question how to determine the str_offsets_base to use.
This seems to require to lookup the CU DIE(s) that refers to the line
table and see if one of them has a DW_AT_str_offsets_base.

While this is possible, it isn't very efficient when just parsing the
.debug_line table itself.

Would it make sense to add the str_offsets_base to the line table
header (for DWARF6)?

Or am I missing a better/simpler way to handle DW_FORM_strx in
.debug_line tables? Or maybe using DW_FORM_strx forms in the
.debug_line table is not something that is really done (I haven't
actually found any producer which does).

Cheers,

Mark
-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Martin via Dwarf-discuss]

On 16/05/2024 18:46, David Blaikie via Dwarf-discuss wrote:
On Thu, May 16, 2024 at 7:10 AM Martin via Dwarf-discuss 
> 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.


Thanks for the answer, but I am not quite sure how to interpret it.

"None that I can think of" => So, it would be ok for a producer to add a 
DW_AT_low_pc ?


But
- "producers don't do that" => It would not be ok?
- "only produce a subprogram declaration" => not ok

If there is code (with debug info) that uses a class/struct that is 
defined in a unit with debug info (or at least a base class is in such a 
unit), then IMHO the debugger should be able to show the entire 
structure, including fields/methods from that unit without debug info. 
(because only the type is in the other unit, but the variable itself is 
in a unit with debug info).


For that, the declaration of that class can be repeated. But if the user 
then wants to call (from the debugger) a function on that (base-) class, 
then it needs the DW_AT_low_pc?


What is the recommended way for the producer to supply this?


About your answers regarding the linking, I will keep that in mind, when 
discussing it with the others involved.
For info, my background is on implementing the debugger. The compiler is 
done by others. But obviously both ends need to work together.


Thanks
Martin
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

[Martin via Dwarf-discuss]

On 16/05/2024 21:58, Martin via Dwarf-discuss wrote:



If there is code (with debug info) that uses a class/struct that is 
defined in a unit with debug info (or at least a base class is in such a 


Tiny but important mistake..., it meant to write

 uses a class/struct that is defined in a unit *WITHOUT* debug info


unit), then IMHO the debugger should be able to show the entire 
structure, including fields/methods from that unit without debug info. 
(because only the type is in the other unit, but the variable itself is 
in a unit with debug info).


For that, the declaration of that class can be repeated. But if the user 
then wants to call (from the debugger) a function on that (base-) class, 
then it needs the DW_AT_low_pc?


What is the recommended way for the producer to supply this?



--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss