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

[Joel Brobecker <brobecker at ACT-Europe dot FR>]

[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