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