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

Jan Kratochvil jan.kratochvil at redhat.com
Mon Nov 19 12:52:28 UTC 2012


On Mon, 19 Nov 2012 11:52:53 +0100, Mark Wielaard wrote:
> BTW. I am not fully sure it cannot be in dwfl_module_addrsym. But I am
> really uncomfortable with creating synthetic symbols.

It only depends on which container you prefer for the returned information.

As GElf_Sym perfectly matches all the information we need to return I have
reused the structure.  Sure one can generated any other similar structure or
return it all in separate function parameters.


> I really hate the name synthetic, can't we call it something like
> dwfl_module_func_addrname ()

So you want this one?

/* Find the symbol that is nearest ADDRESS, and return its name.  Return
   the real symbol addressin *FUNCADDR.  Return also possibly dereferenced
   function descriptors.  */
extern const char *dwfl_module_func_addrname (Dwfl_Module *mod,
                                              GElf_Addr address,
                                              GElf_Addr *funcaddr);

I find confusing to have "func" in its name as it can return arbitrary symbol
type.  OTOH if it really should return only function types then it is
difficult as for example (1) from .S sources symbols commonly have no type or
(2) one should also recognize STT_GNU_IFUNC as a function type which opens
a larger unsure can of function-like symbols.


> > /* 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?

As the data structure perfectly matches to what the caller wants to know.


> 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.

So you want this one?

extern const char *dwfl_module_func_addrsym (Dwfl_Module *mod,
					     GElf_Addr address, GElf_Sym *sym,
					     GElf_Word *shndxp,
					     GElf_Addr *funcaddr);

Here is again the controversy whether this "func"-called function should
return all symbol types or just function symbol types.


> > 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.

Finding just function types is not useful in practice, we need to find any
symbol type.  And then the new interface fully supersedes the old interface.


Thanks,
Jan


More information about the elfutils-devel mailing list