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

[Mark Wielaard <mjw at redhat dot com>]

On Wed, 2012-12-05 at 14:40 +0100, Jan Kratochvil wrote:
> On Wed, 05 Dec 2012 12:30:21 +0100, Mark Wielaard wrote:
> > But I am not entirely sure what the *shndxp value should point to. I
> > guess for an "altered" function symbol it will still always point to the
> > function descriptor (.odp) section. So then if the user really cares
> > then they can inspect the shndxp value returned to see whether the
> > st_value really falls into it (I guess this is just an oddity those on
> > function descriptor based arches need to life with). What is your
> > opinion here?
> 
> My opinion was in the original patch post.  It was adjusting *shndxp to the
> VMA-matching section (therefore usually the .text section).

If we could keep the symbol values, except the adjusted st_value intact
that would have my preference. If you adjust shndxp, do you also adjust
sym.st_shndx?

> > And I am still not really happy about the altered name thing though. I
> > really think we should just return the name of the ELF symbol against
> > which we resolved the address. Dynamically creating strings seems messy.
> 
> Do you care about the name having a dot or do you care about dynamically
> creating strings?  Those two issues are very separate ones.

Both :) The symbol name against which we are matching is what it is, we
shouldn't change its name IMHO. And currently it is clear the elf data
contains the names. Adding more memory pools is asking for trouble.

Cheers,

Mark