[Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0

[Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0

[cel at us dot ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

            Bug ID: 108996
           Summary: Proposal for adding DWARF call site information got
                    GCC with -O0
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cel at us dot ibm.com
  Target Milestone: ---

On PowerPC, the address of the buffer to return non-trivial values such as
structures is passed in register r3.  The value of r3 on entry may change in
the body of the caller.  Thus the contents of r3 can not be used by GDB at the
function exit to access the address of the buffer.  

GDB needs to have the value of r3 on entry to the function to be able to print
the return value of the function when the function exits.  GDB is able to get
the value of r3 from the caller at the time of the function call if the needed
DWARF information is available.  Currently the only way to get the needed DWARF
information is to compile with -fvar-tracking.  The option actually saves lots
of additional information which may negatively impact the size and speed of the
binary when compiled with -O0.  We have not done any investigation to determine
the exact amounts but is based on a best guess.  

GDB doesn't need all the information provided by -fvar-tracking, actually a
small subset of the information.

Currently GDB on PowerPC will attempt to determine the value of r3 on entry. 
If the needed DWARF information is not available, GDB will print the message:

    "Cannot resolve DW_OP_entry_value for the return value.   Try compiling
with -fvar-tracking. “

The following is an example of how gdb is unable to print the return value.  It
is a stripped down version of the gdb testsuite test
gdb/testsuite/gdb.cp/non-trivial-retval.cc.

   class B
   {
   public:
     B () {}
     B (const B &obj);

     int b;
   };

   B::B(const B &obj)
   {
     b = obj.b;
   }

   B
   f2 (int i1, int i2)
   {
     B b;

     b.b = i1 + i2;

     return b;
   }

   int
   main (void)
   {
     int i1 = 23;
     int i2 = 100;

     B b = f2 (i1, i2);
     return 0;
   }


   # compile the program, without -fvar-tracking
   gcc -g -o non-trivial-retval   non-trivial-retval.cc

   # Run GDB


   gdb ./non-trivial-retval
   ...
   gdb) break main
   Breakpoint 1 at 0x10000744: file non-trivial-retval.cc, line 28.
   (gdb) r
   Starting program: /home/carll/GDB/binutils-gdb-
   current/gdb/testsuite/gdb.cp/non-trivial-retval 
   [Thread debugging using libthread_db
   enabled]                                   
   Using host libthread_db library "/lib64/libthread_db.so.1".

   Breakpoint 1, main () at non-trivial-retval.cc:28
   28     int i1 = 23;
   (gdb) n
   29     int i2 = 100;
   (gdb) n
   31     B b = f2 (i1, i2);
   (gdb) s
   f2 (i1=23, i2=100) at non-trivial-retval.cc:18
   18     B b;
   (gdb) finish
   warning: Cannot determine the function return value.       << Message to
user 
   Try compiling with -fvar-tracking.                         << Message to
user      
   Run till exit from #0  f2 (i1=23, i2=100) at non-trivial-
   retval.cc:18
   main () at non-trivial-retval.cc:32
   32     return 0;
   Value returned has type: B. Cannot determine contents       << GDB can not
determine return value
   (gdb) 


   When we compile with -fvar-tracking we can print the return value.

   # Compile with -fvar-tracking
    gcc -g -O0 -fvar-tracking -o non-trivial-retval   non-trivial-retval.cc

   # Run GDB

   gdb ./non-trivial-retval
   (gdb) break main
   Breakpoint 1 at 0x10000730: file non-trivial-retval.cc, line 27.
   (gdb) r
   Starting program: /home/carll/GDB/binutils-gdb-
   current/gdb/testsuite/gdb.cp/non-trivial-retval 
   [Thread debugging using libthread_db
   enabled]                                   
   Using host libthread_db library "/lib64/libthread_db.so.1".

   Breakpoint 1, 0x0000000010000730 in main () at non-trivial-
   retval.cc:27
   27   {
   (gdb) s
   28     int i1 = 23;
   (gdb) s
   29     int i2 = 100;
   (gdb) s
   31     B b = f2 (i1, i2);
   (gdb) s
   0x00000000100006b4 in f2 (i1=i1@entry=23, i2=i2@entry=100)
       at non-trivial-retval.cc:17
   17   {
   (gdb) finish
   Run till exit from #0  0x00000000100006b4 in f2 (i1=i1@entry=23, 
       i2=i2@entry=100) at non-trivial-retval.cc:17
   main () at non-trivial-retval.cc:32
   32     return 0;
   Value returned is $1 = {b = 123}                << GDB can print the return
value

   Looking at the dwarf information, we need to compile with -g -O2 -fvar-
   tracking to get the info we need:

   gcc -g -O0 -fvar-tracking -o non-trivial-retval   non-trivial-retval.cc

   dwarfdump non-trivial-retval > non-trivial-retval.dwarf

   ...
                        DW_AT_GNU_locviews    0x00000039
   < 2><0x000000d6>     DW_TAG_variable
                        DW_AT_name                  b
                        DW_AT_decl_file             0x00000001
                        DW_AT_decl_line             0x0000001f 
                        DW_AT_decl_column           0x00000005 
                        DW_AT_type                  <0x0000002a>
                        DW_AT_location              len 0x0002: 0x9168:
                        DW_OP_fbreg -24


                     This block, is what we need on PowerPC
   < 2><0x000000e3>     DW_TAG_call_site                           
                        DW_AT_call_return_pc        0x10000770      
                        DW_AT_call_origin           <0x00000108>        
   < 3><0x000000f0>     DW_TAG_call_site_parameter                 
                        DW_AT_location              len 0x0001: 0x53:    
                        DW_OP_reg3                                      
                        DW_AT_call_value            len 0x0002: 0x9168:  
                        DW_OP_fbreg -24 


   < 3><0x000000f6>     DW_TAG_call_site_parameter
                        DW_AT_location              len 0x0001: 0x54:
                        DW_OP_reg4
                        DW_AT_call_value            len 0x0004: 0x91609404:
                        DW_OP_fbreg -32
                        DW_OP_deref_size 4
   < 3><0x000000fe>     DW_TAG_call_site_parameter
                        DW_AT_location              len 0x0001: 0x55:
                        DW_OP_reg5
                        DW_AT_call_value            len 0x0004: 0x91649404:
                        DW_OP_fbreg -28
                        DW_OP_deref_size 4

   Given the DW_TAG_call_site_parameter information, specifically for r3 on
PowerPC, GDB is able to determine the return value.  

   The key thing is GDB does not need all of the information that -fvar-  
tracking produces.  It just needs a subset of the information which should be
"easily" to supply.  The issue is being able to enable it by default without
enabling all of the -fvar-tracking information.

   Having this information available on other platforms such as IBM s390 will
enable GDB to be extended on other platforms to print the  return value for
non-trivial return values as well.  

   Things to do:

   1) Determine how hard it would be to output just the minimum information
needed by GDB, i.e. the call site parameter information for the function
argument at the time of the function call.  This   information would be
provided regardless of the optimization level, use of -fvar-tracking. 
Presumably it would only be provided if -g was specified.

   2) Determine how much overhead in terms of the size of the debug
information.

   3) Determine any execution time performance degradation occurs due to the
additional information.

   If it is determined the overhead is minimal, then push the functionality
into GCC.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-03
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
           Severity|normal                      |enhancement
            Version|unknown                     |13.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It might be possible to run a reduced dataflow var-tracking at -O0 for this
kind of things (the target could provide a set of interesting entry/exit
parameters/registers to track).  For other targets the biggest issue is when
debugging the prologue code.

I'm not sure how easy it would be to run var-tracking for a subset of
insns/regs and how to then make use of such partial information when
outputting DWARF.

Alex/Jakub might have some ideas.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think there are several open PRs about var-tracking at -O0, which would be
nice e.g. for VLAs.  The main problem is that var-tracking is very expensive,
so if we do it, it should track a very small subset of what is normally tracked
(say primarily register vars (i.e. what doesn't live at -O0 in memory) and
expressions before they are fully initialized and stored into their memory
slots.
Regarding the call sites, I guess we could get at least some arguments there by
just scanning a few instructions before each call rather than actually tracking
the values,
say on x86_64 the f2 call is:
(insn 33 6 8 2 (set (reg:DI 0 ax [84])
        (plus:DI (reg/f:DI 6 bp)
            (const_int -12 [0xfffffffffffffff4]))) "pr108996.C":31:22 241
{*leadi}
     (nil))
(insn 8 33 9 2 (set (reg:SI 1 dx [85])
        (mem/c:SI (plus:DI (reg/f:DI 6 bp)
                (const_int -8 [0xfffffffffffffff8])) [4 i2+0 S4 A64]))
"pr108996.C":31:22 83 {*movsi_internal}
     (nil))
(insn 9 8 11 2 (set (reg:SI 2 cx [86])
        (mem/c:SI (plus:DI (reg/f:DI 6 bp)
                (const_int -4 [0xfffffffffffffffc])) [4 i1+0 S4 A32]))
"pr108996.C":31:22 83 {*movsi_internal}
     (nil))
(insn 11 9 12 2 (set (reg:SI 4 si)
        (reg:SI 2 cx [86])) "pr108996.C":31:22 83 {*movsi_internal}
     (nil))
(insn 12 11 13 2 (set (reg:DI 5 di)
        (reg:DI 0 ax [84])) "pr108996.C":31:22 82 {*movdi_internal}
     (nil))
(call_insn 13 12 14 2 (call (mem:QI (symbol_ref:DI ("_Z2f2ii") [flags 0x3] 
<function_decl 0x7fe1245e3500 f2>) [0 f2 S1 A8])
        (const_int 0 [0])) "pr108996.C":31:22 1003 {*call}
     (expr_list:REG_EH_REGION (const_int 0 [0])
        (nil))
    (expr_list:DI (use (reg:DI 5 di))
        (expr_list:SI (use (reg:SI 4 si))
            (expr_list:SI (use (reg:SI 1 dx))
                (nil)))))
aka
        leaq    -12(%rbp), %rax
        movl    -8(%rbp), %edx
        movl    -4(%rbp), %ecx
        movl    %ecx, %esi
        movq    %rax, %rdi
        call    _Z2f2ii
so we could from just scanning the above sequence determine that first argument
is &[bp - 12], second argument [bp - 4] and third [bp - 8].
Of course using DW_OP_entry_value in DWARF expressions would be much harder.

But, on the other side, the r3 in the powerpc case (aka &b) is spilled in the
f2's prologue like other parameters, and e.g. debug info
for the b return value says that correctly:
        mflr 0
        std 0,16(1)
        std 31,-8(1)
        stdu 1,-64(1)
        mr 31,1
        std 3,32(31)
        ^^^ above
and
        .byte   0x1      # uleb128 0x1; (DIE (0xcc) DW_TAG_variable)
        .ascii "b\0"     # DW_AT_name
                         # DW_AT_decl_file (1, pr108996.C)
        .byte   0x1f     # DW_AT_decl_line
        .byte   0x8      # DW_AT_decl_column
        .4byte  0x2a     # DW_AT_type
        .byte   0x2      # uleb128 0x2; DW_AT_location
        .byte   0x91     # DW_OP_fbreg
        .byte   0x68     # sleb128 -24
Like everywhere else, the debug info at -O0 isn't accurate before the
corresponding memory slot is initialized, in this case in the first 5
instructions of the function.
But otherwise it is there.  Except that DWARF doesn't say that b is the return
value...

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What is done on other arches?  I mean the situation is basically the same on
x86_64,
where the artificial return value pointer argument is spilled early, then
clobbered
on calls and again b debug info is correct after the spill:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $16, %rsp
        movq    %rdi, -8(%rbp)
        movl    %esi, -12(%rbp)
        movl    %edx, -16(%rbp)
        movq    -8(%rbp), %rax
        movq    %rax, %rdi
        call    _ZN1BC1Ev
        movl    -12(%rbp), %edx
        movl    -16(%rbp), %eax
        addl    %eax, %edx
        movq    -8(%rbp), %rax
        movl    %edx, (%rax)
        nop
        movq    -8(%rbp), %rax
        leave
        ret
...
        .byte   0x1     # uleb128 0x1; (DIE (0xcc) DW_TAG_variable)
        .ascii "b\0"    # DW_AT_name
                        # DW_AT_decl_file (1, pr108996.C)
        .byte   0x1f    # DW_AT_decl_line
        .byte   0x8     # DW_AT_decl_column
        .long   0x2a    # DW_AT_type
        .byte   0x2     # uleb128 0x2; DW_AT_location
        .byte   0x91    # DW_OP_fbreg
        .byte   0x64    # sleb128 -28

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[uweigand at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #4 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> What is done on other arches?

That depends on the platform ABI.  On some arches, including x86/x86_64 and
arm/aarch64, the ABI requires the generated code reloads the return buffer
pointer into a defined register at function exit (either the same it was in on
function entry, or some other ABI-defined register).  On those arches, GDB can
at least inspect the return value at the point the function return happens.

On a few arches, in particular SPARC and RISC-V, the ABI even guarantees that
the return buffer pointer register remains valid throughout execution of the
function, so that GDB can inspect and/or modify the return value at any point.

But on most other arches, including s390x and ppc/ppc64, the ABI does not
guarantee anything, so GDB simply cannot access the function return value at
all (after the point the return buffer pointer register is no longer needed by
generated code and the register has been reused).

However, *if* the debug info contains an entry-value record for that register
at the call site in the current caller, then the return buffer can be accessed
at any time, on all arches.   Given that in this specific case, most callers
will actually just point the return buffer register to a local stack buffer
(i.e. set the register to "stack pointer plus some constant"), generating an
entry-value record for these special cases should actually be quite
straightforward for the compiler, without requiring a lot of value-tracking
machinery.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
> 
> That depends on the platform ABI.  On some arches, including x86/x86_64 and

Ah, you're right here, such functions effectively return that invisible return
address pointer on x86.
Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
(or could be) involved, then GDB needs to punt.
So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have some
way for the compiler to specify DW_AT_location for the return value.
Then for -O1+ -g with var-tracking that address could be for PowerPC r3
register in such functions or wherever its initial value is tracked (including
DW_OP_entry_value).
While for -O0, we'd see we've spilled that parameter to stack and would set
DW_AT_location to that place spilled on the stack.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[mark at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #6 from Mark Wielaard <mark at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.

There is https://dwarfstd.org/ShowIssue.php?issue=221105.1 "Add a mechanism for
specifying subprogram return value locations"

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
> 
> That depends on the platform ABI.  On some arches, including x86/x86_64 and
> arm/aarch64, the ABI requires the generated code reloads the return buffer
> pointer into a defined register at function exit (either the same it was in
> on function entry, or some other ABI-defined register).  On those arches,
> GDB can at least inspect the return value at the point the function return
> happens.

aarch64 does not require that. GCC produces it yes but that is a missed
optimization, see PR 103010 which I filed against GCC for that case.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[uweigand at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #8 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> (or could be) involved, then GDB needs to punt.

The only way a tail call could happen is if the return value is
passed through directly to the (caller's) caller, so the return
buffer address should still be correct, right?

> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.
> Then for -O1+ -g with var-tracking that address could be for PowerPC r3
> register in such functions or wherever its initial value is tracked
> (including DW_OP_entry_value).
> While for -O0, we'd see we've spilled that parameter to stack and would set
> DW_AT_location to that place spilled on the stack.

I don't think it is possible to track the value in the callee - the value may
not be available *anywhere* because it is no longer needed.  (Also, I don't
think the implicit return buffer address is guaranteed to be spilled to the
stack even at -O0.)

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[uweigand at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #9 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Ulrich Weigand from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > What is done on other arches?
> > 
> > That depends on the platform ABI.  On some arches, including x86/x86_64 and
> > arm/aarch64, the ABI requires the generated code reloads the return buffer
> > pointer into a defined register at function exit (either the same it was in
> > on function entry, or some other ABI-defined register).  On those arches,
> > GDB can at least inspect the return value at the point the function return
> > happens.
> 
> aarch64 does not require that. GCC produces it yes but that is a missed
> optimization, see PR 103010 which I filed against GCC for that case.

Well, I was looking at GDB code that at least *assumes* that the aarch64 ABI
does require that:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/aarch64-tdep.c;h=5b1b9921f87e588f8251a77d858f8f312be1e5ac;hb=HEAD#l2500

If this is incorrect, I guess GDB would have to be fixed.

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> > (or could be) involved, then GDB needs to punt.
> 
> The only way a tail call could happen is if the return value is
> passed through directly to the (caller's) caller, so the return
> buffer address should still be correct, right?

If there is just a single possible tail call, I think GDB still handles it,
so that would be ok.  But if you have multiple possible tail calls, I think GDB
for DW_OP_entry_value evaluation punts (at least should, because it doesn't
know which
sequence of calls has been taken).

> I don't think it is possible to track the value in the callee - the value
> may not be available *anywhere* because it is no longer needed.  (Also, I
> don't think the implicit return buffer address is guaranteed to be spilled
> to the stack even at -O0.)

Well, at -O0 we can certainly guarantee it is available somewhere, even if we
currently don't do it already (it would surprise me if it is not spilled).