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

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

On Thu, 06 Dec 2012 15:27:06 +0100, Mark Wielaard wrote:
> 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

You "think" but you give no use cases.  Even Roland was asking for "I think
it's extremely helpful if you give [...] example of the API change you are
proposing." (although one can find other statements supporting your API).


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

So what would be the user/caller of such function?  The facts are:

* Any current caller of dwfl_module_addrsym wants to call the "new" function
  providing even the synthetic symbols.

* There is no use/caller of non-synthetic dwfl_module_addrsym.

So the solutions are two:

(1) * Rename dwfl_module_addrsym to dwfl_module_addrsym_pure_elf.
    * Create some ld script magic to keep ABI - but no API - compatibility.
    * Create new dwfl_module_codesym function also decoding descriptors.
    * Modify all the current callers of dwfl_module_addrsym to call
      dwfl_module_codesym instead.

(2) * Extend dwfl_module_addrsym to decode also descriptors.


> but just return the data from the symbol table that

Why?  The caller wants more than just the data from the symbol table.

If you really want to examine the ELF symbol table you should use
dwfl_module_getsymtab and dwfl_module_getsym.


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

Why?  The caller wants them tweaked.


> I don't agree with you that we should generate some synthetic symbols,
> names, etc, that is just not what these functions do.

It is not my idea, it is a requirement of existing callers, such as addr2line,
my backtracer and in fact also any other caller.


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

It is nothing unknown, BFD IMO in fact defines the ABI for archs like ppc64
and BFD generates the synthetic symbols.  You cannot create better ppc64 ABI
than existing ppc64 ABI, which is defined by BFD.


> Except for adjusting the st_value as we already do that is just
> too painful and messy IMHO.

One could find adjusting st_value also messy in such case, bias could be
applied by the caller.


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

That is the solution (1) above; yes, we can go that way.


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

I agree, this is why I find (2) more feasible.  But I am OK with (1).


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

Please rephrase this paragraph, it seems to contradict everything you have
said above so I probably do not understand it correctly.


Thanks,
Jan