On Tue, 2012-12-04 at 17:37 +0100, Jan Kratochvil wrote:
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
Yes.
(STT_FUNC and STT_GNU_IFUNC).
There are more symbol types that could describe code.
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.
But they do different things. One is just a straight ELF Symbol value ==
address match. The other is about resolving addresses to code.
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.
Yes, because dwfl_module_addrsym resolves symbol values, not addresses.
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.
I am not sure that specific restriction to STT_FUNC is correct or
necessary. The user provides an code address, if they provide an address
that isn't really a code address, but to some random data then I am not
sure we really care. But if you like to have a restriction/sanity check
on the code address we return then you could check that it is in an
executable section for example.
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.
Why would they? If they want to resolve a code address they should use
the new dwfl_module_codesym function. If they want to resolve an address
to a symbol value they should use dwfl_module_addrsym.
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.
If you find it complicated and bug-prone then we haven't yet found a
good interface I am afraid.
Cheers,
Mark