From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EC64F3858D33; Thu, 2 Mar 2023 20:28:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC64F3858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677788936; bh=ZmO+43cKzQ6yn8nhvoZ+qfLvkIoiFgvRQl7g6m/Ur/U=; h=From:To:Subject:Date:From; b=NHalftEqDwWSHU9lVgbGnWNrkMbVE4LOcmTgGMPBThHYxz/zDhL5/Tf+8QG2EnQnP h3k3tsw5T0fuuk1HsFG3S9s+RSqND6qsJFr6gjf50/0FEo7cPxXeOXjPXhT4OE342b n/2oWLUXb8b5QXWpcd/cl+eqKDk1pnHN9pS4p/8Q= From: "cel at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0 Date: Thu, 02 Mar 2023 20:28:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cel at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108996 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.=20=20 GDB needs to have the value of r3 on entry to the function to be able to pr= int the return value of the function when the function exits. GDB is able to g= et the value of r3 from the caller at the time of the function call if the nee= ded DWARF information is available. Currently the only way to get the needed D= WARF information is to compile with -fvar-tracking. The option actually saves l= ots 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 deter= mine the exact amounts but is based on a best guess.=20=20 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= .=20 If the needed DWARF information is not available, GDB will print the messag= e: "Cannot resolve DW_OP_entry_value for the return value. Try compiling with -fvar-tracking. =E2=80=9C 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 =3D obj.b; } B f2 (int i1, int i2) { B b; b.b =3D i1 + i2; return b; } int main (void) { int i1 =3D 23; int i2 =3D 100; B b =3D 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=20 [Thread debugging using libthread_db enabled]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main () at non-trivial-retval.cc:28 28 int i1 =3D 23; (gdb) n 29 int i2 =3D 100; (gdb) n 31 B b =3D f2 (i1, i2); (gdb) s f2 (i1=3D23, i2=3D100) at non-trivial-retval.cc:18 18 B b; (gdb) finish warning: Cannot determine the function return value. << Message to user=20 Try compiling with -fvar-tracking. << Message to user=20=20=20=20=20=20 Run till exit from #0 f2 (i1=3D23, i2=3D100) 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 n= ot determine return value (gdb)=20 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=20 [Thread debugging using libthread_db enabled]=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20 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 =3D 23; (gdb) s 29 int i2 =3D 100; (gdb) s 31 B b =3D f2 (i1, i2); (gdb) s 0x00000000100006b4 in f2 (i1=3Di1@entry=3D23, i2=3Di2@entry=3D100) at non-trivial-retval.cc:17 17 { (gdb) finish Run till exit from #0 0x00000000100006b4 in f2 (i1=3Di1@entry=3D23,=20 i2=3Di2@entry=3D100) at non-trivial-retval.cc:17 main () at non-trivial-retval.cc:32 32 return 0; Value returned is $1 =3D {b =3D 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=20 DW_AT_decl_column 0x00000005=20 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=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 DW_AT_call_return_pc 0x10000770=20=20=20=20= =20=20 DW_AT_call_origin <0x00000108>=20=20=20= =20=20=20=20=20 < 3><0x000000f0> DW_TAG_call_site_parameter=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 DW_AT_location len 0x0001: 0x53:=20=20= =20=20 DW_OP_reg3=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 DW_AT_call_value len 0x0002: 0x9168:=20= =20 DW_OP_fbreg -24=20 < 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.=20=20 The key thing is GDB does not need all of the information that -fvar-=20= =20 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 wi= ll enable GDB to be extended on other platforms to print the return value for non-trivial return values as well.=20=20 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.=20 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.=