[patch] Resolve ppc64 func descriptors as .func (via .opd)
Jan Kratochvil
jan.kratochvil at redhat.com
Tue Dec 4 16:37:09 UTC 2012
On Tue, 04 Dec 2012 11:55:42 +0100, Mark Wielaard wrote:
> I was just wondering if we could express this more generically. But I
> admit to not immediately see how without adding complicating callbacks
> as filter functions. The main point was that this function should IMHO
> not be expressed in terms of filtering/transforming symbols through a
> architecture backend function that gives you the name associated with a
> code address.
You have written every part of the rest of mail as if dwfl_module_codesym
returned only symbols for code (STT_FUNC and STT_GNU_IFUNC).
But the current implementation is just a superset of dwfl_module_addrsym,
besides all the symbols dwfl_module_addrsym returns now dwfl_module_codesym
returns also the resolved function descriptors.
I also still do not understand why dwfl_module_addrsym should exist as I had
to replace all the calls of dwfl_module_addrsym in elfutils to call
dwfl_module_codesym (or equivalent dwfl_module_codename) instead. This also
means any 3rd party code is currently buggy (=not resolveding code addresses
on ppc64) as it still uses dwfl_module_addrsym and not dwfl_module_codesym.
If it should refuse to resolved anything besides code (STT_FUNC/STT_GNU_IFUNC)
then I will have to implemented there such restriction, it is not there.
But then it means every caller will have to call both dwfl_module_addrsym and
dwfl_module_codesym and choose the result from which one it returns.
I can implement it that way (=adding there the STT_FUNC/STT_GNU_IFUNC
restriction to dwfl_module_codesym and changing all the current callers of
dwfl_module_addrsym to ALSO call dwfl_module_codesym and choose one of the
results) but I find it very complicated and bug-prone for the callers.
Thanks,
Jan
More information about the elfutils-devel
mailing list