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

[Daniel Jacobowitz]

On Fri, Apr 12, 2002 at 10:28:03AM +0200, Joel Brobecker wrote:
> > 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.

I think it's a good idea.  I do not know of any current consumers of
this information besides DBX, and I doubt DBX wants the
DECL_ASSEMBLER_NAME.  You'd need a GCC maintainer's opinion on that,
though.

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

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