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 20:23:23 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Mon, Nov 19, 2012 at 01:52:28PM +0100, Jan Kratochvil wrote:
> On Mon, 19 Nov 2012 11:52:53 +0100, Mark Wielaard wrote:
> > BTW. I am not fully sure it cannot be in dwfl_module_addrsym. But I am
> > really uncomfortable with creating synthetic symbols.
> It only depends on which container you prefer for the returned information.
> As GElf_Sym perfectly matches all the information we need to return I have
> reused the structure. Sure one can generated any other similar structure or
> return it all in separate function parameters.
I think it is good to return the original symbol information (when requested)
and not just the derived information.
> > I really hate the name synthetic, can't we call it something like
> > dwfl_module_func_addrname ()
> So you want this one?
> /* Find the symbol that is nearest ADDRESS, and return its name. Return
> the real symbol addressin *FUNCADDR. Return also possibly dereferenced
> function descriptors. */
> extern const char *dwfl_module_func_addrname (Dwfl_Module *mod,
> GElf_Addr address,
> GElf_Addr *funcaddr);
Yes, or maybe an GElf_Off that provides the offset from the start of the
named code block associated with the given address. Since I think the name
and the offset from the start of the code block is what is usually needed.
One can of course derive one from the other, so it doesn't really matter
I think whether you provide the address or offset.
> I find confusing to have "func" in its name as it can return arbitrary symbol
> type. OTOH if it really should return only function types then it is
> difficult as for example (1) from .S sources symbols commonly have no type or
> (2) one should also recognize STT_GNU_IFUNC as a function type which opens
> a larger unsure can of function-like symbols.
Yeah, you are right. How about dwfl_module_codename ()?
> extern const char *dwfl_module_func_addrsym (Dwfl_Module *mod,
> GElf_Addr address, GElf_Sym *sym,
> GElf_Word *shndxp,
> GElf_Addr *funcaddr);
> Here is again the controversy whether this "func"-called function should
> return all symbol types or just function symbol types.
How about dwfl_module_codesym() for this one?
> Finding just function types is not useful in practice, we need to find any
> symbol type. And then the new interface fully supersedes the old interface.
Maybe if we can express this generically as a "filter" that lets you select
which symbols you are interested in and how to transform the matching
function symbol value (through architecture specific hooks)?
But I do think this is a different function from the generic symbol (name)
one. This is to get code name/addresses.