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

Jan Kratochvil jan.kratochvil at redhat.com
Tue Dec 4 15:27:22 UTC 2012


On Tue, 04 Dec 2012 16:18:04 +0100, Mark Wielaard wrote:
> I do think both examples are relevant. We don't really care whether it
> is a "DWARF" or "ELF" symbol,

We are already repeating ourselves.

We can state we disagree and we probably won't find an agreement.  From my
point of view I see the difference in that I choose the standardized and
technially more clean way while you choose more (in your eyes) user convenient
way.  To that point I can add there are no ppc64 end users, on ppc64 there are
only ppc64 aware developers.


> since what we want is mapping a code address to a name.

The problem is that you will then display ELF symbols "funcname" resolved from
address 0xcodeaddr but the ELF symbol "funcname" resolves to address
0xdescriptoraddr.  This is inconsistent output.

After one implements one day also the name->addr referencing of code-address
symbols you will get ambiguous resolution of "funcname" to both
0xdescriptoraddr and 0xcodeaddr, which one to choose then?


> We don't have to add extra dots in front of the actual function names.

Unfortunately we have to as if we don't then we clash with an existing and
valid name (with 0xdescriptoraddr value).


> We already have the real function name.

What is "real"?  If you want to call the function you need the
0xdescriptoraddr.  If you want to display the function code instructions you
need 0xcodeaddr.  There is no "better" kind of symbol, there are just two
kinds of symbol.


> IMHO you are doing extra work to mangle a normal name into something that
> resembles an artificial BFD symbol name. And that is what I think is
> irrelevant in the elfutils case.

I find very unfortunate if elfutils is going to complicate the current ppc64
naming situation even more.


Thanks,
Jan


More information about the elfutils-devel mailing list