This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 07 Dec 2012 13:39:36 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Thu, 06 Dec 2012 16:35:24 +0100, Mark Wielaard wrote:
> Like how you would use in a backtrace (it matches the
> "DWARF way" of doing backtraces in gdb).
"DWARF way" is irrelevant here. elfutils currently do not provide any such
high level functionality of decoding DWARF. Let's keep talking about ELF.
> > 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.
> Could you give examples of these?
See above. I do not know well other elfutils applications besides
> > 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.
> I think I gave a specification of how we should do (2) with a backend
> hook that just matches the st_value to a function address.
Then I probably overlooked it in that amound of mail. I only remember
proposals how to keep dwfl_module_addrsym functionality the same (=broken)
while proposing new functions doing the dwfl_module_addrsym functionality
correctly (=including function descriptors).
> > > but just return the data from the symbol table that
> > Why? The caller wants more than just the data from the symbol table.
> OK, then I am confused about your use case. Could you give an example of
> how you want to use this function?
../src/addr2line -S -e testfile66 0x250
from jankratochvil/ppc64-opd .
> > > 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.
> Because that is the contract of these functions, it seems we disagree on
> that then?
Existing callers of dwfl_module_addrsym want to get the address 0x250
resolved. As it is not possible with in-file ELF symtab the returned ELF
symbol needs to be tweaked some way.
> > > 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.
> I think the name of the symbol as is is fine for these callers.
Skipping this as off-topic for the first part of the discussion what should
dwfl_module_addrsym do except for the returned name.
> > > 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.
> But it is what is done now.
When we are designing new API and from the current discussion it seems to me
we must not change saint dwfl_module_addrsym no matter what it does then the
new API can do anything we want, if you want it just for pure in-file ELF
symbols then even st_value must not be changed.
But then the new API becomes only a very simple (and primarily accelerated)
interface to dwfl_module_getsymtab and dwfl_module_getsym. I do not think
anyone asks for that functionality, dwfl_module_getsymtab and
dwfl_module_getsym are fine on their own for the callers needing them.
> You said you liked me to be explicit and provide a
> specification of what I would like to see implemented. That was this:
> > 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.
> Everything else was just to explain why I think other options are not
> appropriate. The above IMHO provides the simplest semantics for these
> functions that are consistent with how they work now and give meaningful
> results when used with architectures that happen to use function
> descriptors in the symbol table.
OK, so I hope you agree now with the original patch post except the name it
If we agree on that part we can move to the separate second phase of
discussion, about the name.