Re: symtab/1379: GDB doesn't scope nested functions properly

[Jim Ingham <jingham at apple dot com>]

The following reply was made to PR symtab/1379; it has been noted by GNATS.

From: Jim Ingham <jingham@apple.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: symtab/1379: GDB doesn't scope nested functions properly
Date: Wed, 17 Sep 2003 11:19:08 -0700

 On Sep 16, 2003, at 7:44 PM, Daniel Jacobowitz wrote:
 
 > On Tue, Sep 16, 2003 at 06:32:52PM -0000, jingham@apple.com wrote:
 >>
 >>> Number:         1379
 >>> Category:       symtab
 >>> Synopsis:       GDB doesn't scope nested functions properly
 >>> Confidential:   no
 >>> Severity:       serious
 >>> Priority:       medium
 >>> Responsible:    unassigned
 >>> State:          open
 >>> Class:          change-request
 >>> Submitter-Id:   net
 >>> Arrival-Date:   Tue Sep 16 18:38:00 UTC 2003
 >>> Closed-Date:
 >>> Last-Modified:
 >>> Originator:     jingham@apple.com
 >>> Release:        Top of tree as of 09-16-2003
 >>> Organization:
 >>> Environment:
 >> Gnu Linux
 >>> Description:
 >> Compile the file attached to the report for PR 1195.  You will have 
 >> to use -gstabs+, because of 1195, you won't be able to see subproc at 
 >> all with Dwarf.
 >>
 >> Then break in main and step into nested and from there into subproc.
 >>
 >> Now try to do:
 >>
 >> (gdb) print w
 >> No symbol "w" in current context.
 >>
 >> That is wrong, "w" is in fact visible to subproc.  If you want to 
 >> test this, change
 >>
 >> int t = z + 1;
 >>
 >> to
 >>
 >> int t = z + w + 1
 >>
 >> and this will compile fine...
 >>
 >> Fixing this will be a bit of a bear, since you are going to have to 
 >> scope the nested function - into the correct place in the block 
 >> structure of its main program.  Stabs doesn't really tell you where 
 >> the nested function is defined, but once you noticed that it was 
 >> nested (stabs does tell you this) you could go to the line table for 
 >> the function, find the first line, then go to the nesting function, 
 >> find where that line number is in its block structure, and insert the 
 >> nested function there.  Yecch...
 >>
 >> Dwarf2 actually records the nested function in the correct place in 
 >> the blocks already.  But gdb is going to have to start noticing this 
 >> at all before it can handle the scoping problem.
 >
 > I've got some plans (for inline functions) that might end up fixing
 > this for DWARF2.  But I really don't like the idea of this sort of hack
 > in stabs.  I spent a while making nested classes and namespaces work in
 > stabs, but I'm not even planning to submit it; it's too gross, and
 > there's too much guessing involved.  Extend stabs to report it
 > explicitly if you want it supported.  Or switch to DWARF2.
 >
 > My two cents, for whatever they're worth, which is probably nothing.
 >
 
 
 I totally agree with you, and I didn't really intend to try to hack 
 this into the stabs reader.  It would actually be a little harder than 
 I described, because gcc seems to prefer emitting the nested functions 
 first, so you would have to hold onto them waiting till you saw the 
 enclosing function to get the block they belong in.  This seems very 
 fragile to me.
 
 And my policy is to not add anything to stabs itself unless someone 
 holds a gun to my head.  But I keep an accumulating list of "stuff that 
 is hard to do in stabs" so I can justify the resources to convert our 
 toolchain to using Dwarf...
 
 Jim
 --
 Jim Ingham                                   jingham@apple.com
 Developer Tools
 Apple Computer