This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 2012-12-04 at 17:37 +0100, Jan Kratochvil wrote:
> On Tue, 04 Dec 2012 11:55:42 +0100, Mark Wielaard wrote:
> > I was just wondering if we could express this more generically. But I
> > admit to not immediately see how without adding complicating callbacks
> > as filter functions. The main point was that this function should IMHO
> > not be expressed in terms of filtering/transforming symbols through a
> > architecture backend function that gives you the name associated with a
> > code address.
> 
> You have written every part of the rest of mail as if dwfl_module_codesym
> returned only symbols for code

Yes.

> (STT_FUNC and STT_GNU_IFUNC).

There are more symbol types that could describe code.

> But the current implementation is just a superset of dwfl_module_addrsym,
> besides all the symbols dwfl_module_addrsym returns now dwfl_module_codesym
> returns also the resolved function descriptors.
>
> I also still do not understand why dwfl_module_addrsym should exist as I had
> to replace all the calls of dwfl_module_addrsym in elfutils to call
> dwfl_module_codesym (or equivalent dwfl_module_codename) instead.

But they do different things. One is just a straight ELF Symbol value ==
address match. The other is about resolving addresses to code.

> This also
> means any 3rd party code is currently buggy (=not resolveding code addresses
> on ppc64) as it still uses dwfl_module_addrsym and not dwfl_module_codesym.

Yes, because dwfl_module_addrsym resolves symbol values, not addresses.

> If it should refuse to resolved anything besides code (STT_FUNC/STT_GNU_IFUNC)
> then I will have to implemented there such restriction, it is not there.

I am not sure that specific restriction to STT_FUNC is correct or
necessary. The user provides an code address, if they provide an address
that isn't really a code address, but to some random data then I am not
sure we really care. But if you like to have a restriction/sanity check
on the code address we return then you could check that it is in an
executable section for example.

> But then it means every caller will have to call both dwfl_module_addrsym and
> dwfl_module_codesym and choose the result from which one it returns.

Why would they? If they want to resolve a code address they should use
the new dwfl_module_codesym function. If they want to resolve an address
to a symbol value they should use dwfl_module_addrsym.

> I can implement it that way (=adding there the STT_FUNC/STT_GNU_IFUNC
> restriction to dwfl_module_codesym and changing all the current callers of
> dwfl_module_addrsym to ALSO call dwfl_module_codesym and choose one of the
> results) but I find it very complicated and bug-prone for the callers.

If you find it complicated and bug-prone then we haven't yet found a
good interface I am afraid.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]