Re: [RFC PATCH] Fix PPC64 ELF ABI v2 symbol address retrieval

[Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>]

Mark Wielaard <mjw@redhat.com> wrote on 26.01.2015 15:09:08:

> That is a strict reading, but you are right. The execution can indeed
> start at either point. So an attribute on the subroutine might be the
> wrong thing to use. What about using a DW_TAG_entry_point (DWARF 3.3 "An
> alternate entry point") as child of the DW_TAG_subroutine to describe
> the local entry point?

Well, this DWARF feature also doesn't really match very well to the
PowerPC situation.  DW_TAG_entry_point is supposed to be used for
languages (like some Fortran versions, I think) that support multiple
entry point *at the source level*, where the alternate entry point has
its own name and argument list.  This is why DW_TAG_entry_point requires
its own DW_AT_name attribute, and needs to provide its own argument and
return type information ...

While of course it might be possible to create all that information for
an ELFv2 local entry point (synthesizing a name and duplicating the
type information), that seems needlessly complex.

As as I said before, I don't think there is any feature in DWARF4 that
is intended to allow specifying something like ELFv2 local entry points.
I guess there would be one way or another to do so by non-standard use
of some feature, or by making use of a platform-specific extension;
one relatively straightforward way would be to use a set of private
values of the DW_AT_calling_convention attribute to specify the entry
point offset values that can be encoded in st_other.

However, given that at this stage we already probably have on the order
of 100000 binaries in the field that were compiled without that
information, and none of the existing compilers in production use
(which is not just GCC, but at least also LLVM and XLC) produces that
information, I'm wondering how useful it would be to make such a change
at this stage.  Tools would have to implement the fallback to look at the
symbol table anyway to cope with existing binaries, and once that is
implemented, having the information duplicated in DWARF doesn't really
buy you anything ...

> > Some few use cases (like yours) do require the local entry point, but
> > you can always find the local entry point via the symbol table if you
> > know the global entry point (but not necessarily vice versa).
>
> But I do think it is a fairly common use case. Users often want to make
> sure they can monitor all calls to a particular function. The lookup
> through the symbol table is possible, but not very efficient. Because
> there is no direct link between the two, just an indirect match by
> checking the sym value and name against the DIE low_pc and (mangled)
> name. Although I admit that is partly because elfutils doesn't provide
> an efficient symbol table search, just a linear one (I do have to fix
> that).

That would seem useful anyway, there's other interesting info in the
symbol table (like symbol visibility etc.).

Bye,
Ulrich