[Bug compile/34456] ppc64le: "compile" command corrupts addresses of inferior symbols (-mcmodel=medium TOC16 relocation overflow)

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

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Abhay Kandpal <[email protected]>:

https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D36af47b3a834=
8b9ff9c717100c44049c6f3d6315

commit 36af47b3a8348b9ff9c717100c44049c6f3d6315
Author: Abhay Kandpal <[email protected]>
Date:   Wed Jul 29 08:20:33 2026 -0500

    PowerPC: Fix compile command by reverting to default code model

    On ppc64le, the "compile" command produces corrupted code when the
    compiled expression takes the address of a symbol in the inferior.
    For example:

      (gdb) break -qualified main
      (gdb) run
      (gdb) compile code pmf =3D &A::get_var1
      (gdb) x/2gx &pmf
      0x7fffffffeb68:  0x0000800010000d78  0x0000000000000000

    The stored address is wrong: the low 32 bits are correct
    (0x10000d78, the true address of A::get_var1) but bit 47 is
    incorrectly set.  When the compiled code later calls through such a
    pointer the inferior jumps to unmapped memory and receives SIGSEGV.

    Commit 533f04079c7 ("[gdb] [rs6000] Add
    ppc64_linux_gcc_target_options method.") made ppc64 return an empty
    string from gdbarch_gcc_target_options, overriding the
    "-m64 -mcmodel=3Dlarge" that default_gcc_target_options supplies for
    64-bit targets, so GCC uses -mcmodel=3Dmedium instead.

    With the medium model, references to the inferior's symbols are
    compiled as TOC-relative accesses using R_PPC64_TOC16_HA/LO
    relocations, whose combined displacement is a signed 32-bit value
    (+/- 2GB).  GDB allocates the compiled module in the inferior with an
    mmap that the kernel places in the high mmap region (e.g. around
    0x7ffff7f30000), while the inferior's own text is low (e.g. around
    0x10000000).  The distance between them is close to 2^47, far beyond
    the reach of a TOC16 relocation, so the displacement is silently
    truncated to 32 bits, producing an address that is off by 2^47.

    Revert 533f04079c7 so that ppc64 again uses
    default_gcc_target_options ("-m64 -mcmodel=3Dlarge").  With the large
    model GCC emits a real .toc section and loads addresses as full
    64-bit values from it, so the only TOC-relative references are into
    the module's own .toc, always in range wherever the module is mapped.
    The .TOC. handling from commit bad23de3543 ("[gdb] Handle .TOC.
    sections during gdb-compile for rs6000 target.") still applies, now
    resolving via the genuine .toc section rather than the .text fallback
    the medium model required.

    Tested on powerpc64le-linux (Fedora, GCC 15.2.1).

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D34456

    gdb/
            * ppc-linux-tdep.c (ppc64_linux_gcc_target_options): Remove.
            (ppc_linux_init_abi): Don't set gcc_target_options.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=