On Tue, 2012-11-13 at 16:18 +0100, Jan Kratochvil wrote: > On Tue, 13 Nov 2012 15:20:55 +0100, Mark Wielaard wrote: > > 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. > > Yes. > > > (At least SystemTap assumes b) symbols areavailable in ET_REL files.) > > Such symbols are available in every ET_* file.
Interesting. I thought the linker removed the dot-symbols. But I don't have a ppc64 setup around to check. If those are always available, then why do we even bother with the symbols pointing to the function descriptors in the first place? I have to admit that I am still a little unclear on what problem exactly you are fixing. Could you give an example? Where did you get the address from that you call dwfl_module_addrsym () on and why are you not satisfied with getting the ELF symbol that address lies inside? > > 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 not understand this part. What does mean "kind is available"? So there are two symbols available for each function on ppc64. One with the name of the function that points to the address of the descriptor. And one, with the name of the function prefixed with a dot, that points to the actual function entry. I am wondering which symbol is currently being returned for dwfl_module_addrsym () and which one is returned with your proposed change. My confusion might come from not knowing whether or not both symbols are always available in all cases. > > 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. > > I do not see it could cause any problem. I find .funcname->addr lookup as an > additional and mostly unrelated feature. > > If you require so I can rewrite the patch to support also .funcname->addr > lookup. But say so. No, you are right that is a different kind of lookup. Lets concentrate on dwfl_module_addrsym () first. > > 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)? > > I am against such special case as "nobody" tests new code with ppc64 and any > such difference visible only on ppc64 will need to be continually fixed by > people having ppc64 access. Yes, but it isn't really a special case for ppc64. They really are slightly different things. Currently dwfl_module_addrsym () is about low-level ELF symbol lookup by address. But what you really want is function name lookup by address. Which is a slightly higher-level concept. So I don't think it is strange to have separate interfaces for it. You could even make it (optionally) do demangling, which 'dot-stripping' kind of is. But again, I admit to still not fully understand the problem you are solving. So the above might be nonsense for the actual case you are trying to fix. Sorry. Cheers, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
