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

[Mark Wielaard <mjw at redhat dot com>]

On Tue, 2012-12-04 at 16:27 +0100, Jan Kratochvil wrote:
> 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.

We currently disagree. But lets try to find some agreement anyway.

>   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.

I would say that my point of view is that I want things to be consistent
across architectures. What we are after is a mapping from addresses to
function names. I believe that can be consistent across architectures,
it should not matter whether the architecture uses function descriptors
or not. The interface we are working on is precisely to abstract that
away.

> 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.

That would be inconsistent indeed. But that is not what we should do. We
have functions for working with ELF symbols and their values. What we
are defining now are functions for working with addresses and functions
(were the user doesn't have to care about function descriptors).

> 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?

0xcodeaddr

> > 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).

But a 0xdescriptoraddr isn't a valid value for code address is it?
That is a data pointer, not a code address.

> > We already have the real function name.
> 
> What is "real"?  If you want to call the function you need the
> 0xdescriptoraddr.

Yes, but that is again a different interface IMHO.

>   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.

Isn't there just one symbol? We only interpret/use the value of that
symbol differently (or actually the architecture specific backend code
does) depending on how we want to use it.

Cheers,

Mark