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

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

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.

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


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

I look only what is needed by the caller.

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

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.

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.


Thanks,
Jan