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 Sun, 2012-11-18 at 10:46 +0100, Jan Kratochvil wrote:
> On Fri, 16 Nov 2012 23:28:26 +0100, Roland McGrath wrote:
> > I agree with Mark that this does not belong in dwfl_module_addrsym.

BTW. I am not fully sure it cannot be in dwfl_module_addrsym. But I am
really uncomfortable with creating synthetic symbols. IMHO we should
only return symbols as they come from a symbol table we have around. It
might be that we don't match on symbol value, but match a given address
against some architecture specific way derived from the symbol/value.
And maybe return an alternative architecture specific name. That might
expand the contract so much that we are better of creating a new
interface of course.

> New patch included.
> 
> jankratochvil/ppc64-opd2

> > Perhaps what will be used most often is something with different
> > semantics: yield a name and corresponding address near the given
> > address.
> 
> /* Find the symbol that *ADDRESS lies inside, and return its name.  Return also
>    its starting address in modified *ADDRESS.  Return also possibly runtime
>    generated artificial symbols such as resolved function descriptors.  */
> extern const char *dwfl_module_addrname_synthetic (Dwfl_Module *mod,
>                                                    GElf_Addr *address);
> 
> This is something between dwfl_module_addrname and dwfl_module_addrsym.
> IMO the format interface was better, one either wants just the name or one is
> interested in possibly all the other attributes (such as the function size).

I really hate the name synthetic, can't we call it something like
dwfl_module_func_addrname () and make the description say this return
the function name that is nearest the address? I think I would like it a
little better if there was just a separate argument GElf_Addr *funcaddr
that returned the found function address instead of reusing the input
argument address. But I don't have a very strong opinion on that.

> > Or perhaps you want to describe those semantics as, yield an ELF symbol
> > (i.e. not just name, but also section, scope, and visibility info) and
> > corresponding address near the given address.
> 
> /* Find the symbol that ADDRESS lies inside, and return detailed
>    information as for dwfl_module_getsym (above).  Return also possibly
>    runtime generated artificial symbols such as resolved function
>    descriptors.  */
> extern const char *dwfl_module_addrsym_synthetic (Dwfl_Module *mod,
>                                                   GElf_Addr address,
>                                                   GElf_Sym *sym,
>                                                   GElf_Word *shndxp)

Same here, why do you need to return synthetic symbols? Returning the
symbol from which the function name was derived seems all that is
needed. You should just add an extra parameter GElf_Addr *funcaddr (or
reuse the address argument like you did above) to return the address
where the function is.

> In my opinion there exists no real world case when one wants to use the "old"
> interface (without synthetic symbols).  It will happen one incorrectly uses
> the non-synthetic variant while one always wants to use the synthetic variant,
> making it broken on ppc64 which nobody has access to / can test.

IMHO they do different things. The old interface finds ELF symbols where
the value is near the given address. This new interface finds functions
near a given address.

Cheers,

Mark

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