This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]