This is the mail archive of the elfutils-devel@sourceware.org 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, 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.

> > > You need about that looked up function symbol also the function size, starting
> > > code address, visibility and binding.  It is mostly the whole GElf_Sym
> > > structure (except you do not need numerical st_name and st_shndx is probably
> > > also not useful). This is all returned by dwfl_module_addrsym in my original
> > > post.
> > 
> > OK, but you can just use the function descriptor symbol for that can't
> > you? There is nothing an synthetic generated symbol would add is there?
> 
> 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.

Cheers,

Mark

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