This is the mail archive of the
elfutils-devel@sourceware.org
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: Tue, 13 Nov 2012 15:20:55 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Wed, 2012-10-10 at 09:57 +0200, Jan Kratochvil wrote:
> On Wed, 10 Oct 2012 01:59:23 +0200, Roland McGrath wrote:
> > For this kind of thing, I think it's extremely helpful if you give a
> > short description and example of the API change you are proposing. I
> > can read and respond to that much more quickly than I can review the
> > implementation.
>
> There is new:
>
> libebl/ebl-hooks.h:
> +/* *SYM must be STT_FUNC. Then if it describes a function descriptor (PPC64)
> + convert in-place its data and return a possibly different new name for it.
> + The name is valid as long as EBL is valid. */
> +const char *EBLHOOK(get_func_pc) (Ebl *ebl, struct Dwfl_Module *mod,
> + GElf_Sym *sym);
>
> And dwfl_module_addrsym starts working on ppc64 the way it should.
A questions on the semantics of dwfl_module_addrsym with this change.
As far as I understand Function Descriptor symbols there are two kind of
symbols:
a) symbols with the same name as the the function, with as value the
address of the descriptor.
b) symbols with a name that start with a dot (.) plus the function
name, with as value the actual function entry point.
(At least SystemTap assumes b) symbols areavailable in ET_REL files.)
If the b) kind is available then dwfl_module_addrsym will return it (and
the dot-prefixed name), but if it isn't then a) will be returned (normal
name and sym value != address)?
I do think that semantic is what the user would expect. But it is a
slight change of semantics. I doubt anything would break. But there is a
slight chance something might depend on the not getting any symbol
unless sym value == address.
Also, do you think users of dwfl_module_addrsym () are really after the
symbol? It looks like they are really after just the name. So might it
make sense have an explicit (new) function:
const char *dwfl_module_funcname (Dwfl_Module *mod, GElf_Addr address)
that just translates an address to a function name without the user ever
seeing the symbol used for the translation (as alternative of
dwfl_module_addrname)?
Thanks,
Mark