This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 19 Nov 2012 11:37:20 +0100
- Subject: 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
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: <20121118094626.GA5136@host2.jankratochvil.net>
> which IIUC you have not commented in this mail yet.
Not yet indeed.