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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 04 Dec 2012 17:02:57 +0100, Mark Wielaard wrote:
> 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.

We should be consistent but in ppc64 case it means that function is
represented by its function descriptor.  The code address is completely hidden
from the programs, we can almost forget any code addresses exist, programs act
as if descriptor is the function.

#include <stdio.h>
extern void _start(void);
int main(void) {
  return printf("_start=%p\nmain=%p\n",_start,main);
}
$ ./s;readelf -Wa ./s|egrep -w 'Entry|_start|main'
_start=0x10010a50
main=0x10010aa0
  Entry point address:               0x10010a50
    60: 0000000010010a50    60 FUNC    GLOBAL DEFAULT   22 _start
    62: 0000000010010aa0   120 FUNC    GLOBAL DEFAULT   22 main

There is just no code address anywhere.  This also justifies the dot-prefied
variant, it is some almost-never-used form which is inappropriate for any use.


The mess happens only when we start dealing with DWARF symbols.  I believe they
should have been dot-prefixed.
But DWARF symbols are outside of this / elfutils discussion.


> What we are defining now are functions for working with addresses and
> functions

If we deal with functions we deal with function descriptors, this justifies
the shifting of the bizarre dot-prefixed code address into a forgotten land
(=dot-prefixed land).


> (were the user doesn't have to care about function descriptors).

The ppc64 developer does not care about the code addresses.


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

In 95% of cases not, see above.  Only during reverse-engineering / crash
analysis you start to care about code addresses, never during programming or
static analysis.


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

Right.


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

I have no idea of the intended interface so I am not replying to this item.


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

We can call it just one symbol but I find it easier to call them two symbols.
Just as the one of them is easily runtime generated from the other one the
file format optimized the one kind of symbol out.


Thanks,
Jan