Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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.

(gdb) bt
#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
> 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.


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
	https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002765.html
	Message-ID: <20121118094626.GA5136@host2.jankratochvil.net>
which IIUC you have not commented in this mail yet.


Thanks,
Jan