[Bug runtime/17638] Symbol resolution broken for PPC64 ABIv2

["uweigand at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17638

Ulrich Weigand <uweigand at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uweigand at gcc dot gnu.org

--- Comment #3 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
The DWARF address ranges deliberately include the *whole* function,
both global and local entry points.  GDB relies on that behavior.  (For
one, if you look up the function belonging to the current PC, you should
find the correct one even if you're before the local entry point.)

If you want to set probes on a local entry point, you should look up the
symbol in the main symbol table (not DWARF), and check the st_other bits;
they will indicate whether the function has a local entry point, and what
its offset from the global entry point is.  Note that GDB does the same
when setting a breakpoint on a function entry.

You can use the PPC64_LOCAL_ENTRY_OFFSET macro from the binutils header
files (elf/ppc64.h) to decode the st_other bits.  See also the GDB routines
ppc_elfv2_elf_make_msymbol_special and ppc_elfv2_skip_entrypoint (in the
GDB patch linked to above).

Anton's kernel patch refered to above instead implements code parsing
in an attempt to detect the typical global entry point sequence.  This
should work OK for now, but might cause problems in the future if the
sequence generated by GCC (or another compiler) ever changes.  Thus,
using the ELF symbol st_other bits is certainly the prefered way.

-- 
You are receiving this mail because:
You are the assignee for the bug.