Re: .n suffixes for function names in stabs debug info (GCC 3.1-based compiler)

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Apr 12, 2002 at 10:43:07AM +0200, Joel Brobecker wrote:
> [I removed gcc@gcc.gnu.org, as this discussing is now taking a
> GDB-specific turn]
> 
> Summary: I define a function called "inside" nested into function main.
> Compiling with a gcc-3 backend using -gstabs+, I found that GDB is
> having problems putting a breakpoint on function "inside":
> 
> > > (gdb) b inside
> > > Function "inside" not defined.
> > > (gdb) b inside.0 <<----  Argh, need to give the name with the (right!) suffix
> > > Breakpoint 1 at 0x8048579: file hello.c, line 4.
> > > >>
> 
> I pointed the source of the problem to the stabs line, were the ".0"
> suffix was now present. Daniel Jacobowitz kindly answered that
> GCC is right to put this suffix in the name before the ':' :
> 
> > According to that, your example:
> > > .stabs  "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0
> > 
> > should be:
> > > .stabs  "inside.0:f(1,1)=(1,1),inside,main",36,0,4,inside.0
> 
> What do you think of the scenario above? Is it acceptable that the user
> has to use "inside.0" (and guess the right prefix) rather than "inside"
> to break on this function? I suppose that this case does not happen very
> often in C, and completion should help the user find which prefixes are
> used.

Certainly it isn't acceptable.

> Since this happens more often in Ada, I'd like to fix it at least in the
> ada mode.
> 
> I have found two possibilities:
>   (1) either enhance our ada "mode" in GDB to support these suffixes
>       (I think this should not be too difficult, but other languages
>       would not benefit from it)
>   (2) or modify GDB in a language-independent manner. I'm not sure what
>       the best way to achieve this would be yet, maybe by stripping
>       these suffixes from the names read from the stabs info and from
>       the symbols table? But at the same time this may disturb the
>       support of other languages such as, maybe, c++.
> 
> What do you think?

The proper solution is:
 - urge the namespace/scope discussions onward.
 - Support reading those functions into the proper scope.

At that point you'll have to reference them as 'main::inside', probably
(or 'inside' if you're in main currently).  Not an obvious syntax...
but the most reasonable, I think.  And the results of 'info func
inside' will show a 'main::inside', which should be enough of a hint.


Jim, that raises one question.  How are we going to support searching
for a name in all scopes, a la `info func'?  It seems that it might be
prohibitively more expensive than it is currently...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer