This is the mail archive of the
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: Sun, 18 Nov 2012 18:25:22 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Sun, 18 Nov 2012 17:27:07 +0100, Mark Wielaard wrote:
> On Sun, 2012-11-18 at 09:31 +0100, Jan Kratochvil wrote:
> > So in some cases dot-symbols aware elfutils return different symbol name while
> > former elfutils returned also some (but different) symbol.
> But you are not actually interested in these none-function symbols are
> you? You seem to want an interface that returns function
> names/addresses. dwfl_module_addrsym () returns any ELF symbol.
I want to get information about code at that point.
If there is no better symbol I want even the sizeless symbols like
__vmx__sigsetjmp_ent as that code (which for example crashed) can be from
assembly source where people commonly forget to specify .size directives.
> > You can never say "inside any of the ELF symbols", there are symbol priorities
> > libdwfl/dwfl_module_addrsym.c
> > /* Return GELF_ST_BIND as higher-is-better integer. */
> > inline int binding_value (const GElf_Sym *symp)
> > where the "better" symbols override the "worse" symbols. When the "better"
> > dot symbol is missing elfutils still can use some "worse" symbol instead.
> Is the specific ordering of better/worse in dwfl_module_addrsym ()
> correct for your use case? For example, do you even care about
> STT_OBJECT symbols?
Not for STT_OBJECT. But I care about global vs. static, size vs. sizeless,
weak vs. non-weak etc. symbols.
> > 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.
#0 0x00000000100004d0 in .f ()
#1 0x0000000010000500 in .main ()
> 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.
> 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
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
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
which IIUC you have not commented in this mail yet.