This is the mail archive of the
mailing list for the elfutils project.
Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 16 Nov 2012 14:31:53 +0100
- Subject: Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)
On Tue, 2012-11-13 at 16:18 +0100, Jan Kratochvil wrote:
> On Tue, 13 Nov 2012 15:20:55 +0100, Mark Wielaard wrote:
> > A questions on the semantics of dwfl_module_addrsym with this change.
> > As far as I understand Function Descriptor symbols there are two kind of
> > symbols:
> > a) symbols with the same name as the the function, with as value the
> > address of the descriptor.
> > b) symbols with a name that start with a dot (.) plus the function
> > name, with as value the actual function entry point.
> > (At least SystemTap assumes b) symbols areavailable in ET_REL files.)
> Such symbols are available in every ET_* file.
Interesting. I thought the linker removed the dot-symbols.
But I don't have a ppc64 setup around to check. If those are always
available, then why do we even bother with the symbols pointing to the
function descriptors in the first place?
I have to admit that I am still a little unclear on what problem exactly
you are fixing. Could you give an example? Where did you get the address
from that you call dwfl_module_addrsym () on and why are you not
satisfied with getting the ELF symbol that address lies inside?
> > If the b) kind is available then dwfl_module_addrsym will return it (and
> > the dot-prefixed name), but if it isn't then a) will be returned (normal
> > name and sym value != address)?
> I do not understand this part. What does mean "kind is available"?
So there are two symbols available for each function on ppc64. One with
the name of the function that points to the address of the descriptor.
And one, with the name of the function prefixed with a dot, that points
to the actual function entry. I am wondering which symbol is currently
being returned for dwfl_module_addrsym () and which one is returned with
your proposed change. My confusion might come from not knowing whether
or not both symbols are always available in all cases.
> > I do think that semantic is what the user would expect. But it is a
> > slight change of semantics. I doubt anything would break. But there is a
> > slight chance something might depend on the not getting any symbol
> > unless sym value == address.
> I do not see it could cause any problem. I find .funcname->addr lookup as an
> additional and mostly unrelated feature.
> If you require so I can rewrite the patch to support also .funcname->addr
> lookup. But say so.
No, you are right that is a different kind of lookup. Lets concentrate
on dwfl_module_addrsym () first.
> > Also, do you think users of dwfl_module_addrsym () are really after the
> > symbol? It looks like they are really after just the name. So might it
> > make sense have an explicit (new) function:
> > const char *dwfl_module_funcname (Dwfl_Module *mod, GElf_Addr address)
> > that just translates an address to a function name without the user ever
> > seeing the symbol used for the translation (as alternative of
> > dwfl_module_addrname)?
> I am against such special case as "nobody" tests new code with ppc64 and any
> such difference visible only on ppc64 will need to be continually fixed by
> people having ppc64 access.
Yes, but it isn't really a special case for ppc64. They really are
slightly different things. Currently dwfl_module_addrsym () is about
low-level ELF symbol lookup by address. But what you really want is
function name lookup by address. Which is a slightly higher-level
concept. So I don't think it is strange to have separate interfaces for
it. You could even make it (optionally) do demangling, which
'dot-stripping' kind of is.
But again, I admit to still not fully understand the problem you are
solving. So the above might be nonsense for the actual case you are
trying to fix. Sorry.