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 Sun, 2012-11-18 at 18:25 +0100, Jan Kratochvil wrote:
> > > Symbol name of the function descriptor with added leading dot.
> > 
> > The leading dot is weird. That is just some low-level ppc64 ABI
> > convention that seems confusing if what you are after is the actual
> > function name. That name is without the dot. It makes sense if you are
> > constructing some synthetic symbol that matches that ABI, but I don't
> > think it makes sense in this use case.
> This is what I am used to from GDB.  I find any other notation confusion as on
> ppc64 one expects it this way.
> (gdb) bt
> #0  0x00000000100004d0 in .f ()
> #1  0x0000000010000500 in .main ()

IMHO that is just weirdness/bug in GDB. There is no function with such a
name. You are just printing the name of a synthetic BFD symbol with a
made up name. What value does it add for the user to print it like that?

> > Then instead of using dwfl_module_addrsym () I would suggest a new
> > interface for looking up function names by address.
> Do you mean dwfl_module_addrname?  This works that way in my original post.

Yes, if you are only interested in the function name.

> > And if you include any ELF symbol then make it the ELF symbol from which the
> > function was derived. So the actual function descriptor symbol in this case.
> > I don't see a need to generate synthetic symbols, they don't seem to add
> > anything.
> 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?

> I still believe the most suitable interface is what I have implemented in my
> original post.  If you mean anything else I am fine with implementing whatever
> else but please explicitly specify what I should implement.  I have already
> implemented some other interface I guessed you may mean in
> 	Message-ID: <>
> which IIUC you have not commented in this mail yet.

Not yet indeed.



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