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

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2012-12-05 at 16:54 +0100, Jan Kratochvil wrote:
> On Wed, 05 Dec 2012 16:04:11 +0100, Mark Wielaard wrote:
> > No. Lets keep the shndxp/sym.shndx values as they are.
> 
> I do not mind, OK, I do not see what is shndxp/sym.shndx for the caller good
> for.

Good. Lets drop munging the shndxp/sym.shndx.

> Although the only idea of its use I have is that an application may have
> general logic for translation of ELF symbols from .opd section, in this case
> it would then try to double-translate such symbol (which would fortunately
> fail as VMA is then not from the .opd section anymore).

Could you give an example of what you have in mind here? If you think it
is relevant and/or might help me understand your use case.

> > Because then we change the contract of the function even more. Just
> > changing the st_value can be seen as how the function already works (we
> > consider resolving the function descriptor address just like adjusting
> > the st_value for the module location), but stretching it to do other
> > things too means we really should look into a new function for new
> > functionality.
> 
> I really do not mind any function contracts.

But keeping a sane/simple interface is important.

> I look only what is needed by the caller.

Then maybe you do need a completely different function after all?

> Caller needs a function which works universally for any address, returning any
> type of matching symbol, including resolving of function descriptors.

OK, I think we can provide that through dwfl_module_addrsym () if we let
the backend detect function descriptor symbols and return that
symbol/name if the address matches. That is what I propose you
implement.

> And I already tried to explain multiple times why the code symbols need to be
> differently named and that such different name is already defined by ppc64 ABI.

Indeed, I still don't see why this is relevant. The address will match
the function descriptor symbol and name. Not some synthetic code symbol.
As far as I can see the returned name and symbol information is what the
user wants/needs.

> If we have not found an agreement on that part then the next step is to get an
> approval from IBM.  I would find very unfriendly to break their ABI standard
> in common standard package without even letting them know.

Please do ask if you think that is helpful. I might be missing why it is
relevant/important. Having more opinions will certainly be welcome.

But I think just returning what is in the symbol table and not trying to
munch the returned values from what we already have is good enough.

Cheers,

Mark