This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 19 Nov 2012 13:58:25 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Mon, 19 Nov 2012 13:53:12 +0100, Mark Wielaard wrote:
> On Mon, 2012-11-19 at 13:14 +0100, Jan Kratochvil wrote:
> > On Mon, 19 Nov 2012 11:37:20 +0100, Mark Wielaard wrote:
> > > On Sun, 2012-11-18 at 18:25 +0100, Jan Kratochvil wrote:
> > > > (gdb) bt
> > > > #0 0x00000000100004d0 in .f ()
> > > > #1 0x0000000010000500 in .main ()
> > >
> > > IMHO that is just weirdness/bug in GDB.
> >
> > No matter what it is it is a standard.
>
> Sure for some low-level/synthetic ELF symbol name ABI.
> But I don't see why that has to leak through to the user in a backtrace
> where they just want to know which function name corresponds to a
> specific address. The extra dot doesn't add any value in this case and
> is just confusing.
It is because at that "in XXX ()" place is always displayed a symbol name.
The symbol name is ".funcname".
The symbol name cannot be "funcname" as then it would clash with the function
descriptor symbol "funcname".
All together implying the backtrace has to display "in .main ()".
> > In the function descriptor symbol ST_VALUE points to the descriptor.
> > In the synthetic generated symbol ST_VALUE points to the code entry address.
>
> Right, but we pass around the code entry address separately from the
> symbol.
That depends on the chosen API.
Thanks,
Jan