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

[Joel Brobecker <brobecker@ACT-Europe.FR>]

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