[Converted from Gnats 1195] Gdb seems unable to report any local symbol information within any nested procedure, or any procedure that contains nested procedures. I did not see any similar report in the bug database, but there may be some relation to problems #1180 or #222. The latter was dismissed as "pascal-specific", but it may be in fact an instance of the C problem reported here. Release: gdb 5.3 Environment: intel GNU/Linux Red Hat 2.4.18-14 How-To-Repeat: Compile the attached program and step through it. Notice that function arguments are not listed when the debugger enters the functions "nested" or "subproc". Requests to print local variables of either function report "No symbol ... in current context".
Fix: None known. The "info" documentation does not mention nested functions.
From: Jorge Stolfi <stolfi@ic.unicamp.br> To: nobody@sources.redhat.com, gdb-gnats@sources.redhat.com, stolfi@ic.unicamp.br, gdb-prs@sources.redhat.com Cc: Subject: Re: symtab/1195: no local symbol information within nested or nesting procedures Date: Tue, 29 Apr 2003 10:13:38 -0300 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1195 PS. I actually noticed the problem in the version of gdb that came with Red Hat (gdb 5.2.1-4). I then fetched gdb 5.3 and compiled it locally, but the problem persisited. In all cases the compiler was gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
From: Daniel Jacobowitz <drow@mvista.com> To: stolfi@ic.unicamp.br Cc: gdb-gnats@sources.redhat.com Subject: Re: symtab/1195: no local symbol information within nested or nesting procedures Date: Tue, 29 Apr 2003 09:28:22 -0400 On Tue, Apr 29, 2003 at 01:07:15PM -0000, stolfi@ic.unicamp.br wrote: > > >Number: 1195 > >Category: symtab > >Synopsis: no local symbol information within nested or nesting procedures > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: unassigned > >State: open > >Class: sw-bug > >Submitter-Id: net > >Arrival-Date: Tue Apr 29 13:08:00 UTC 2003 > >Closed-Date: > >Last-Modified: > >Originator: Jorge Stolfi, CS Dept, UNiversity of Campinas > >Release: gdb 5.3 > >Organization: > >Environment: > intel GNU/Linux Red Hat 2.4.18-14 > >Description: > Gdb seems unable to report any local symbol information > within any nested procedure, or any procedure that contains > nested procedures. > > I did not see any similar report in the bug database, but > there may be some relation to problems #1180 or #222. > The latter was dismissed as "pascal-specific", but it > may be in fact an instance of the C problem reported here. > >How-To-Repeat: > Compile the attached program and step through it. > Notice that function arguments are not listed when the > debugger enters the functions "nested" or "subproc". > Requests to print local variables of either function report > "No symbol ... in current context". > >Fix: > None known. The "info" documentation does not mention > nested functions. Please get a CVS snapshot of GDB and try again? This sounds to me much like the DW_AT_ranges problem recently fixed. Directions for accessing CVS can be found at http://sources.redhat.com/gdb/. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
From: Jorge Stolfi <stolfi@ic.unicamp.br> To: Daniel Jacobowitz <drow@mvista.com> Cc: gdb-gnats@sources.redhat.com Subject: Re: symtab/1195: no local symbol information within nested or nesting procedures Date: Sat, 24 May 2003 15:58:43 -0300 Daniel Jacobowitz writes: > Please get a CVS snapshot and try again? This sounds like the > DW_AT_ranges problem recently fixed. I finally got around to fetching the current CVS snapshot (20030524) and compiling it. The current GDB apparently solves only half of the problem. If you step through the tiny sample program that was attached to my original message, you will see that - when inside the "nested" function, gdb now correctly displays the arguments and local variables of that function; - when inside the "subproc" function, gdb displays neither the symbols of that function, nor the symbols of the enclosing function ("nested"). --stolfi
From: Jim Ingham <jingham@apple.com> To: gdb-gnats@sources.redhat.com Cc: Subject: Re: symtab/1195: no local symbol information within nested or nesting procedures Date: Tue, 16 Sep 2003 11:22:54 -0700 Note that this bug is specific to the Dwarf reader. Compile the same .c file with -gstabs+, and you will be able to see local variables, etc. The Dwarf reader seems to skip nested functions altogether. You won't see subproc in "info func" either. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer
I tried this today. It mostly works -- I can step into the nested function and print its arguments and locals. gdb recognizes the symbols from the enclosing function, but it gets their values wrong: (gdb) p w $2 = 5930 (gdb) p x $3 = 5929 (gdb) p y $4 = -1073744072
I looked at this a little more deeply today, with some advice from Roland. The problem in this case is that the 'subproc' function does not reference any variables from its enclosing context. So, gcc does not emit DW_AT_static_link. I think the right thing to do in this case is to throw an error for any variable from the outer function that requires a frame. If you add a mention of 'w' to 'subproc', then the DWARF looks better. However, gdb doesn't ever use DW_AT_static_link, so if you get the right answer it is purely by accident.
I have a patch but I think it requires a gcc bug fix first: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
(In reply to Tom Tromey from comment #8) > I have a patch but I think it requires a gcc bug fix first: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 Could you post your patch, the GCC issue has been fixed for some time.
I think the gdb-side may be fixed already, since: commit 63e43d3aedb8b1112899c2d0ad74cbbee687e5d6 Author: Pierre-Marie de Rodat <derodat@adacore.com> AuthorDate: Thu Feb 5 17:00:06 2015 +0100 Commit: Pierre-Marie de Rodat <derodat@adacore.com> CommitDate: Tue Aug 25 08:13:28 2015 -0400 DWARF: handle non-local references in nested functions
As Pedro noticed, the original issue is solved on the GDB side. Note that it also requires a fix on the GCC side, which should be available in GCC 6 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927#c24).