public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0
@ 2023-03-02 20:28 cel at us dot ibm.com
  2023-03-03  8:37 ` [Bug debug/108996] Proposal for adding DWARF call site information in " rguenth at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: cel at us dot ibm.com @ 2023-03-02 20:28 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-03-07  8:53 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-02 20:28 [Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0 cel at us dot ibm.com
2023-03-03  8:37 ` [Bug debug/108996] Proposal for adding DWARF call site information in " rguenth at gcc dot gnu.org
2023-03-03  9:20 ` jakub at gcc dot gnu.org
2023-03-03  9:24 ` jakub at gcc dot gnu.org
2023-03-03 13:14 ` uweigand at gcc dot gnu.org
2023-03-03 13:51 ` jakub at gcc dot gnu.org
2023-03-03 15:39 ` mark at gcc dot gnu.org
2023-03-03 18:24 ` pinskia at gcc dot gnu.org
2023-03-07  8:46 ` uweigand at gcc dot gnu.org
2023-03-07  8:49 ` uweigand at gcc dot gnu.org
2023-03-07  8:53 ` jakub at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).