This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C ASSEMBLER_NAME patch
On Sat, Jul 26, 2003 at 03:38:53PM -0700, Geoff Keating wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
>
> > On Sat, Jul 26, 2003 at 12:12:54AM -0700, Geoffrey Keating wrote:
> > >
> > > On Friday, July 25, 2003, at 08:12 PM, Michael Elizabeth Chastain
> > > wrote:
> > >
> > > >I have a similar problem with function names transforming from
> > > >"foo" to "foo.0" in the debug info. It's causing a bit of
> > > >heartburn for gdb.
> > > >
> > > >Here is the source code:
> > > >
> > > > static void f1 (int i);
> > > > static void f1 (int i)
> > > > {
> > > > return;
> > > > }
> > > >
> > > >Here is the output from gcc HEAD 20030716:
> > > >
> > > > .stabs "f1:f(0,21)=(0,21)",36,0,3,f1
> > > > .stabs "i:p(0,1)",160,0,2,8
> > > > .type f1, @function
> > > > f1:
> > > > .stabn 68,0,3,.LM1-f1
> > > >
> > > >And here is the output from gcc HEAD 20030722:
> > > >
> > > > .stabs "f1.0:f(0,21)=(0,21)",36,0,3,f1.0
> > > > .stabs "i:p(0,1)",160,0,2,8
> > > > .type f1.0, @function
> > > > f1.0:
> > > > .stabn 68,0,3,.LM1-f1.0
> > > >
> > > >The function name change from "f1" to "f1.0", even though "f1"
> > > >is declared and defined at file scope. This happens with -gstabs+.
> > > >It does not happen with -gdwarf-2 (or if it does, gdb is handling
> > > >it okay).
> > >
> > > This is supposed to happen under some circumstances. (Not the
> > > circumstances that you're experiencing---I'm fixing that now---but some
> > > other circumstances.)
> > >
> > > How should GCC emit stabs so that GDB does the right thing with these
> > > symbol names?
> >
> > The name is supposed to be the function's symbolic name - then we get
> > the actual address from the last argument to .stabs. So it seems to me
> > that it should be:
> >
> > .stabs "f1:f(0,21)=(0,21)",36,0,3,f1.0
> > .stabs "i:p(0,1)",160,0,2,8
> > .type f1.0, @function
> > f1.0:
> > .stabn 68,0,3,.LM1-f1.0
> >
> > That is, the .0 should be trimmed in the string. I think dwarf2out.c
> > already does the equivalent.
>
> Yes, dwarf2out.c uses the DW_AT_MIPS_linkage_name attribute, so it
> should work just fine.
>
> Like most of these problems, I can reproduce it using an older version
> of GCC by writing the right construct:
>
> int main(void)
> {
> int foo(void)
> {
> return 0;
> }
> return foo();
> }
>
> [gkeating@keatge gkeating]$ gcc-3.3 t4.c -g -o t4
> [gkeating@keatge gkeating]$ gdb t4
> GNU gdb 5.3-20030128 (Apple version gdb-282) (Fri Jun 13 03:33:07 GMT 2003)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "powerpc-apple-darwin".
> Reading symbols for shared libraries .. done
> (gdb) break main
> Breakpoint 1 at 0x1dd4: file t4.c, line 7.
> (gdb) run
> Starting program: /private/Network/Servers/cauchy/homes/thorin/gkeating/t4
> Reading symbols for shared libraries . done
>
> Breakpoint 1, main () at t4.c:7
> 7 return foo();
> (gdb) break foo
> Function "foo" not defined.
>
> because you get
>
> .stabs "foo.0:f(0,1)=r(0,1);-2147483648;2147483647;,foo.0,main",36,0,4,_foo.0
>
> so you have to type
>
> (gdb) break foo.0
> Breakpoint 2 at 0x1dac: file t4.c, line 5.
>
> stabs.texinfo is pretty clear, it gives this example:
>
> .stabs "bar:f1,bar,foo",36,0,0,_bar.12
>
> for 'bar' nested inside 'foo'.
Yeah, but I don't know that anyone either emits or parses that. Or
that they don't parse it, either...
>
> Now, I can't just use the language's name of the function always. GDB
> *does* know how to demangle C++ assembler names, so we want to emit
> those when they exist. So what I think I'll do is this algorithm:
>
> if (assembler name of function starts with "_Z")
> use assembler name
> else
> use language's name
>
> Can anyone think of a case where that wouldn't work and a different
> algorithm would?
>
> Can anyone help me test a patch?
Personally, I think we should emit the language's name always - and
either GDB should expect fully qualified demangled C++ names, or else
basenames and we teach GDB/GCC about the stabs namespace qualifiers.
Either works for me.
Why is it necessary to emit the mangled name?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer