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 _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
