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, 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

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.


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