[binutils-gdb] PowerPC: Fix compile command by reverting to default code model

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
   =20
    On ppc64le, the "compile" command produces corrupted code when the
    compiled expression takes the address of a symbol in the inferior.
    For example:
   =20
      (gdb) break -qualified main
      (gdb) run
      (gdb) compile code pmf =3D &A::get_var1
      (gdb) x/2gx &pmf
      0x7fffffffeb68:  0x0000800010000d78  0x0000000000000000
   =20
    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.
   =20
    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.
   =20
    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.
   =20
    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.
   =20
    Tested on powerpc64le-linux (Fedora, GCC 15.2.1).
   =20
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D34456
   =20
    gdb/
            * ppc-linux-tdep.c (ppc64_linux_gcc_target_options): Remove.
            (ppc_linux_init_abi): Don't set gcc_target_options.

Diff:
---
 gdb/ppc-linux-tdep.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c
index 1d54b72bb1d..8a55ff5d4af 100644
--- a/gdb/ppc-linux-tdep.c
+++ b/gdb/ppc-linux-tdep.c
@@ -2076,14 +2076,6 @@ ppc64_gnu_triplet_regexp (struct gdbarch *gdbarch)
   return "p(ower)?pc64"; /* codespell:ignore.  */
 }
=20
-/* Implement the linux_gcc_target_options method.  */
-
-static std::string
-ppc64_linux_gcc_target_options (struct gdbarch *gdbarch)
-{
-  return "";
-}
-
 /* Fetch and return the TLS DTV (dynamic thread vector) address for PTID.
    Throw a suitable TLS error if something goes wrong.  */
=20
@@ -2337,8 +2329,6 @@ ppc_linux_init_abi (struct gdbarch_info info,
 	set_gdbarch_gnu_triplet_regexp (gdbarch, ppc64le_gnu_triplet_regexp);
       else
 	set_gdbarch_gnu_triplet_regexp (gdbarch, ppc64_gnu_triplet_regexp);
-      /* Set GCC target options.  */
-      set_gdbarch_gcc_target_options (gdbarch, ppc64_linux_gcc_target_opti=
ons);
       /* Internal thread local address support.  */
       set_gdbarch_get_thread_local_address (gdbarch,
 					    svr4_tls_get_thread_local_address);