This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)

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

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

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]