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

[Mark Wielaard <mjw at redhat dot com>]

On Thu, 2012-12-06 at 11:00 +0100, Jan Kratochvil wrote:
> On Wed, 05 Dec 2012 17:30:35 +0100, Mark Wielaard wrote:
> > 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.
> 
> I have tried to create such example now but I have found there is no way to
> find out whether *SHNDXP belongs to mod->main or mod->debug.  Therefore the
> parameter is useless.

Thanks, that might indeed be something the user already has to know
beforehand. hmmm. IMHO more reason to not try to change it. But we might
want to think about this issue later.

> Maybe we still do not agree what the function should do.  I expected we have
> already concluded dwfl_module_addrsym should return synthetic symbol for the
> ppc64 instructions addresses and that we only disagree which name should be
> reported for such returned synthetic symbol.
> 
> Sorry but this discussion is somehow dead-end, I do not understand what you
> want to implement.  I can implement whatever you tell me but I have not found
> yet a specification of implementable/working solution.

Sorry, I'll try to be more explicit. But our discussion did make me
change my mind a couple of times. You do make good arguments and clearly
know this stuff. But I am hesitant to change or make any current
functions too different/more complicated than strictly necessary. And
introducing new functions need a lot of thought about what the semantics
really should be.

The root of our disagreement is really just what dwfl_addrsym() is about
1) return just a name associated with a symbol (with possibly the
st_value adjusted for the module/code load address, so it matches) from
a known symbol table we have at hand, or 2) return a (synthetic) ELF
symbol that match some ABI for a particular arch. I think it should be
the first and want minimal/no changes to what gets returned, just enough
to "make a match", you think that if there are any changes needed
necessary to match then it should go "all the way" to make things
consistent with the particular architecture way.

So to be explicit. If we are using the current interfaces
dwfl_module_addrname () and by extension dwfl_module_addrsym () for
returning a symbol name associated with an address then I think we
should be as conservative as possible. So that means not fabricating a
"synthetic" symbol, but just return the data from the symbol table that
we have at hand, where only the st_value is adjusted as documented for
the module load address to match the given address. To make that work
for architectures that use function descriptors add a backend hook that
translates the st_value when appropriate if the original value doesn't
match directly. And that IMHO is really all that is needed.

The current dwfl_module_addrname () and dwfl_module_addrsym () return
the name of that symbol and that seems as good a name as any to return,
so we should not tweak it. Nor should we tweak any other symbol values.
I don't agree with you that we should generate some synthetic symbols,
names, etc, that is just not what these functions do. And it opens a
whole can of worms which values need to be adjusted so they are "in
sync" with the rest of the synthetic value derived from the symbol we
have. Except for adjusting the st_value as we already do that is just
too painful and messy IMHO.

If you really want to return any other different values that describe
the function, or a different name or something that matches synthetic
symbol in agreement with some ppc64 ABI more closely from what we do
now, then we should design a new function. But I don't think that is
really necessary. We tried, but the benefits seem not enough and it
would be confusing since then users would have two similar, but slightly
different functions to call for the same kind of functionality. It is
IMHO better to just use the current functions so that they return a name
also for arches that use function descriptor symbols (and the same name
we would return for any other arch), so that users can use the same
function on all arches to get the same names.

Cheers,

Mark