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

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

[Joel Brobecker]

The code that triggered this question was written in Ada but I
reproduced it using a small C program. This C example may seem a bit
unusual, but the root problem occurs quite often in usual situation when
writting code in Ada, for instance when using overloading, or nested
functions.

Here is a small program:
<<
int
main (void)
{
  void inside (void) {}
  return 0;
}
>>

When compiled using the following command:
% gcc -gstabs+ -S hello.c

GCC generates the following stabs for inside():
<<
.stabs  "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0
               ^^
               ||
>>

This is happening on my x86-linux machine, but I suspect this to be
target independent.

This ".0" suffix, which was not generated with GCC-2 backends,
is causing problems to GDB:

<<
(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.
>>

Do you think that GCC is right in putting these suffixes in the function
name? I see several options:
   (1) GCC is not right, and the suffix should not be there,
       GDB will be fine again
   (2) GCC is right, and GDB should just strip these suffixes while
       reading the stabs information. Disambiguation should be
       done by other means (eg. a multiple choice question)
   (3) GCC is right, and GDB should is right too. The C user need to
       supply the full function name, including the suffix (not
       appealing at all for the Ada users)

The Stabs reference manual is not very acurate on this issue. The
example given in section "Nested procedures" seem to indicate that
(1) is the right answer:
      .stabs "baz:f1,baz,bar",36,0,0,_baz.15
But is not quite clear on this particular issue.
One side-effect of this approach is that the function name in the stabs
information becomes different from the name stored in the symbols table.
But should the name stored in the symbol table also contain this suffix?

If it turns out that (1) is the correct answer, I'll be happy to work on
a fix and discuss it on gcc-patches.
-- 
Joel

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

[Daniel Jacobowitz]

On Thu, Apr 11, 2002 at 06:19:42PM +0200, Joel Brobecker wrote:
> The code that triggered this question was written in Ada but I
> reproduced it using a small C program. This C example may seem a bit
> unusual, but the root problem occurs quite often in usual situation when
> writting code in Ada, for instance when using overloading, or nested
> functions.
> 
> Here is a small program:
> <<
> int
> main (void)
> {
>   void inside (void) {}
>   return 0;
> }
> >>
> 
> When compiled using the following command:
> % gcc -gstabs+ -S hello.c
> 
> GCC generates the following stabs for inside():
> <<
> .stabs  "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0
>                ^^
>                ||
> >>
> 
> This is happening on my x86-linux machine, but I suspect this to be
> target independent.
> 
> This ".0" suffix, which was not generated with GCC-2 backends,
> is causing problems to GDB:

I believe that GCC is wrong, but you are pointing at the wrong error. 
See below a bit.

> 
> <<
> (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.
> >>
> 
> Do you think that GCC is right in putting these suffixes in the function
> name? I see several options:
>    (1) GCC is not right, and the suffix should not be there,
>        GDB will be fine again
>    (2) GCC is right, and GDB should just strip these suffixes while
>        reading the stabs information. Disambiguation should be
>        done by other means (eg. a multiple choice question)
>    (3) GCC is right, and GDB should is right too. The C user need to
>        supply the full function name, including the suffix (not
>        appealing at all for the Ada users)
> 
> The Stabs reference manual is not very acurate on this issue. The
> example given in section "Nested procedures" seem to indicate that
> (1) is the right answer:
>       .stabs "baz:f1,baz,bar",36,0,0,_baz.15
> But is not quite clear on this particular issue.
> One side-effect of this approach is that the function name in the stabs
> information becomes different from the name stored in the symbols table.
> But should the name stored in the symbol table also contain this suffix?

By "the stabs reference manual", I assume you mean the one included
with GDB - yes, I see your example in it.  That's not exactly a
reference manual, unfortunately; it's essentially a whole lot of
observations related to various stabs readers at the time.  Sun
actually publishes a reference manual to stabs, which looks almost
nothing like the stabs that GCC put out.

The one you're looking at says:
   For any of the symbol descriptors representing procedures, after the
symbol descriptor and the type information is optionally a scope
specifier.  This consists of a comma, the name of the procedure,
another comma, and the name of the enclosing procedure.  The first name is
local to the scope specified, and seems to be redundant with the name of the
symbol (before the `:').  This feature is used by GCC, and presumably
Pascal, Modula-2, etc., compilers, for nested functions.

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

"The first name is local to the scope specified", as opposed to "the
name of the symbol (before the `:')".  GDB doesn't actually parse the
scope information, and quite possibly never will, so this doesn't help
you much.  What happens in DWARF-2?

For your information, Jim Blandy and others are working on greatly
improving GDB's support for nested scopes right now; this may fall out
of that, especially for the DWARF-2 case.



All the rest of this is an aside; don't take it to seriously.  GDB
supports none of this.

However, notice in the index of that manual; there are two references
to the Nested Procedures chapters which describe 'I' and 'J', which
don't appear in the manual.  They appear to be an AIX extension.  For
curiousity's sake, I looked them up in Sun's document:
"Stabs Interface Manual, Version 4.0 - February 1999".

According to this document, the stabs should read roughly:
.stabs "inside.0:J(1,1),inside,main", N_FUN, 0, 0, 0
.stabs "inside:W(1,1);inside.0;;;", N_LSYM, 0, 0, 0

(and various other sun stabs to get the arguments of the function and the
location, etc.)

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

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

[Joel Brobecker]

> I believe that GCC is wrong, but you are pointing at the wrong error. 
> See below a bit.

Thank you for this well documented answer.

> 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

Should this be corrected in GCC? There seems to be an easy fix:
Replace DECL_ASSEMBER_NAME by DECL_NAME in

      /* For a nested function, when that function is compiled,
         mention the containing function name
         as well as (since dbx wants it) our own assembler-name.  */
      if (context != 0)
        fprintf (asmfile, ",%s,%s",
                 IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)),
                 IDENTIFIER_POINTER (DECL_NAME (context)));

I can submit a patch if this is worth it.

> For your information, Jim Blandy and others are working on greatly
> improving GDB's support for nested scopes right now; this may fall out
> of that, especially for the DWARF-2 case.

Thanks, I will keep an eye on their progress. Note that I like DWARF2
but I am also interested in stabs for some of our platforms like AiX.

-- 
Joel

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

[Joel Brobecker]

[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.

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?
-- 
Joel

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

[Daniel Jacobowitz]

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

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

[Daniel Berlin]

> 
> 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...

I'm not so sure it would be all that more expensive, but if it was, we
could just throw all names into a global ternary search tree, and use
that for searches against all scopes.

For the example of "info func main", you just walk the tree to main, and
print out all children from there.