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

[Mark Wielaard <mjw at redhat dot com>]

On Fri, 2015-01-23 at 16:17 +0100, Ulrich Weigand wrote:
> Mark Wielaard <mjw@redhat.com> wrote on 23.01.2015 15:00:35:
> 
> > BTW. Would it make sense to let GCC encode this in the DWARF output?
> > DWARF 4, 2.18 Entry Address says:
> >
> >         Any debugging information entry describing an entity that has a
> >         range of code addresses, which includes compilation units,
> >         module initialization, subroutines, ordinary blocks, try/catch
> >         blocks, and the like, may have a DW_AT_entry_pc attribute to
> >         indicate the first executable instruction within that range of
> >         addresses. The value of the DW_AT_entry_pc attribute is a
> >         relocated address. If no DW_AT_entry_pc attribute is present,
> >         then the entry address is assumed to be the same as the value of
> >         the DW_AT_low_pc attribute, if present; otherwise, the entry
> >         address is unknown.
> >
> > Which seems to describe the situation exactly. And would make elfutils
> > libdw dwarf_entrypc () do the right thing automagically (it will fall
> > back to low_pc as described) without needing any extra lookups through
> > symbol tables.
> 
> Well, not really.  The global entry point is also a possible entry point,
> and there are exectuable instructions between the global and the local
> entry point as well.  DW_AT_entry_pc is intended for the case where
> execution *always* starts at some other place than DW_AT_low_pc.  There
> is no provision in DWARF right now to describe that a function has
> *multiple* possible entry points.

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?

> We chose to have the DWARF address range cover the whole function
> (including both entry points), and use the global entry point as
> the "DWARF entry point", since that seemed to work best for most
> users of that information.  For example, GDB relies on that behaviour
> (e.g. if you look up the current function by PC, you want to find
> the function even if you stopped in between the two entry points).

Yes, it is certainly a good choice to make the subprogram DIE cover the
whole function (including both entry points).

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

Cheers,

Mark