From: Abhay Kandpal <abhay@linux.ibm.com>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Abhay Kandpal <Abhay.k@ibm.com>, "cel@linux.ibm.com" <cel@linux.ibm.com>
Subject: Re: [PATCHi v1] PowerPC: Create call stubs for compiled modules
Date: Tue, 18 Aug 2026 23:17:24 +0530 [thread overview]
Message-ID: <9f77ef3d-f40d-4887-9984-2f18447fbadd@linux.ibm.com> (raw)
In-Reply-To: <1a31198de71abfc8f36c893cc97c81b72c6112a7.camel@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]
Hi Ulrich,
Thanks for the suggestion. I tried|-mlongcall| and it doesn't work on PowerPC,
though not for the reason I expected.
gcc does generate the right calling sequence with it - saves r2,
loads the target into r12, uses mtctr/bctrl, restores r2:
24: std r2,24(r1)
30: addis r12,r2,0
30: R_PPC64_PLT16_HA _setjmp
34: ld r12,0(r12)
34: R_PPC64_PLT16_LO_DS _setjmp
80: mtctr r12
80: R_PPC64_PLTSEQ longjmp
84: bctrl
84: R_PPC64_PLTCALL longjmp
88: ld r2,24(r1)
But it obtains the target address from a PLT slot addressed off r2,
so the calls need R_PPC64_PLT16_HA / R_PPC64_PLT16_LO_DS, which BFD's generic linker rejects:
warning: Compiled module "/tmp/gdbobj-6tZVEd/out1.o" section ".text": dangerous relocation: generic linker can't handle R_PPC64_PLT16_HA
warning: Compiled module "/tmp/gdbobj-6tZVEd/out1.o" section ".text": dangerous relocation: generic linker can't handle R_PPC64_PLT16_LO_DS
|-mlongcall| also converts the intra-module call to a PLT call,
so it fails earlier than before - in|_gdb_expr| rather than in the callee.
Same result with|-mcmodel=large -mlongcall| and with|-fno-plt -mlongcall| (|-mno-plt| is not recognised on PowerPC).
So on PowerPC|-mlongcall| gives the correct convention but still requires a PLT,
which is the one thing GDB can't supply. Resolving PLT16 would mean building a table
within +-32KB of the module's TOC and computing slot offsets - more machinery than the stub, not less.
With the patch, GDB builds the target address as immediates instead, needing no table:
call site:
bl <stub>
ld r2,24(r1) ; the nop, rewritten
stub:
std r2,24(r1)
lis r12,target@highest
ori r12,r12,target@higher
rldicr r12,r12,32,31
oris r12,r12,target@h
ori r12,r12,target@l
mtctr r12
bctr
At entry to|_setjmp|, r12 holds the callee's entry address and r2 the correct TOC;
before the patch r2 pointed past the end of libc, which is the SIGSEGV.
The patch applies cleanly to master and gives 526 passes, 0 failures in gdb.compile on powerpc64le.
Thanks
Abhay
On 18/08/26 17:49, Ulrich Weigand wrote:
> Abhay Kandpal<abhay@linux.ibm.com> wrote:
>
>> The compile command loads a module into inferior memory and relocates
>> it itself, without a linker. For R_PPC64_REL24 it patches the branch
>> to point directly at the target. On ELFv2 that is not a valid call to
>> another module: the callee derives its TOC pointer from r12, which
> only
>> a PLT-style call stub sets up, and the caller's TOC pointer is never
>> restored because the nop following the bl is left alone.
> On other platforms, the way this is supposed to work is to use a
> set of compiler command-line options that result in code that does
> not require PLTs for external calls. Typically, this means to use
> -mcmodel=large.
>
> However, it seems that on PowerPC, while that option exists, it
> generates code that still needs PLTs. There is another option
> -mlongcall that should avoid this, however.
>
> I'm wondering if we were to just add -mlongcall to the platform-
> specific compiler options for PowerPC, we could fix this issue
> without having to reimplement a full PLT solution in GDB ...
>
> Bye,
> Ulrich
[-- Attachment #2: Type: text/html, Size: 6790 bytes --]
next prev parent reply other threads:[~2026-08-18 17:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 9:28 Abhay Kandpal
2026-08-18 12:19 ` Ulrich Weigand
2026-08-18 17:47 ` Abhay Kandpal [this message]
2026-08-19 12:39 ` Ulrich Weigand
2026-08-19 18:39 ` Abhay Kandpal
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=9f77ef3d-f40d-4887-9984-2f18447fbadd@linux.ibm.com \
--to=abhay@linux.ibm.com \
--cc=Abhay.k@ibm.com \
--cc=Ulrich.Weigand@de.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