On Tue, 2012-12-04 at 18:30 +0100, Jan Kratochvil wrote: > Because in 99% (100%?) of cases you do not know and do not care which type of > address you want to resolve. See addr2line -S. > > Even if you think you have a code address - like in a crash backtrace - you > could have crashed due to a jump to data buffer. In such case you should > display name of the buffer variable, despite you expected a code address.
OK. You are just too nice. You did write up the whole "different function" that I think we needed, but you don't really believe we should. Making me think I was right :) But (after some sleep) I do see your point. Instead of having a separate "code lookup" function it would be nice if we just had dwfl_module_addrsym () magically handle symbols that point to function descriptors when looking for an address. And maybe my worries that is really too confusing are not warranted. The issues that I saw were that you don't really know if that is what the user wanted. Especially they might be looking for the ELF symbol as function descriptor, so wanting to match against the value, not the translated function address. And you will have to return "fake" ELF symbols and you suggest even altered names, which seems really messy. So my suggestion to work around those issues were to just introduce a new function that does only code address lookup (ignore there are even descriptor symbols or other none-code data symbols) and return altered data/addresses as a separate argument so that the Elf symbol data keeps "pure". But we don't really return a "pure" symbol anyway. The user provides storage for us to construct one (GElf_Sym *sym). And we already say that we will adjust the st_value to the absolute value based on the module location. So adjusting it again by the backend for a function descriptor isn't really a big deal. And if we accept we change the st_value anyway, then first matching against the original value (to find a function descriptor) and then match against an altered value by the backend (the actual function address), should really be fine too. That way the user gets what they want without them needing to know what address they are really providing. But I am not entirely sure what the *shndxp value should point to. I guess for an "altered" function symbol it will still always point to the function descriptor (.odp) section. So then if the user really cares then they can inspect the shndxp value returned to see whether the st_value really falls into it (I guess this is just an oddity those on function descriptor based arches need to life with). What is your opinion here? And I am still not really happy about the altered name thing though. I really think we should just return the name of the ELF symbol against which we resolved the address. Dynamically creating strings seems messy. And that seems to be our only real contention. The need (or not) to return an altered name for the symbol. Lets see if we can find some agreement on that somehow. Thanks, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
