Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Abhay Kandpal <abhay@linux.ibm.com>
To: gdb-patches@sourceware.org
Cc: Ulrich.Weigand@de.ibm.com, cel@linux.ibm.com, abhay.k@ibm.com,
	Abhay Kandpal <abhay@linux.ibm.com>
Subject: [PATCH v2] PowerPC: Fix compile command by reverting to default code model
Date: Tue, 28 Jul 2026 12:50:53 -0500	[thread overview]
Message-ID: <20260728175053.1875987-1-abhay@linux.ibm.com> (raw)

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 = &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=large" that default_gcc_target_options supplies for
64-bit targets, so GCC uses -mcmodel=medium 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=large").  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=34456

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

 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.  */
 }
 
-/* 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.  */
 
@@ -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_options);
       /* Internal thread local address support.  */
       set_gdbarch_get_thread_local_address (gdbarch,
 					    svr4_tls_get_thread_local_address);
-- 
2.52.0


             reply	other threads:[~2026-07-28 17:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28 17:50 Abhay Kandpal [this message]
2026-07-29 13:05 ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260728175053.1875987-1-abhay@linux.ibm.com \
    --to=abhay@linux.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=abhay.k@ibm.com \
    --cc=cel@linux.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox