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

Yes.


> (At least SystemTap assumes b) symbols areavailable in ET_REL files.)

Such symbols are available in every ET_* file.


> 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"?


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


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

This is visible on GDB testcases which usually expect GDB output to be
"funcname" and IBM people have to continually patch there "\\.?funcname".


Thanks,
Jan

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