From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FHFAH9GahGrJJC8AWB0awg (envelope-from ) for ; Tue, 18 Aug 2026 13:48:01 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=gy1PDR6U; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 67CC51E09B; Tue, 18 Aug 2026 13:48:01 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 472611E09B for ; Tue, 18 Aug 2026 13:47:59 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 70F404BA23F8 for ; Tue, 18 Aug 2026 17:47:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70F404BA23F8 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=gy1PDR6U Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 9BF2B4BA23D1 for ; Tue, 18 Aug 2026 17:47:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9BF2B4BA23D1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9BF2B4BA23D1 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787075251; cv=none; b=IRW6wEyPM0rF/RiEZGyr5PfKOoZcMfVmJlXd8XENCeYtLW5JyZiq3/4xHEvMEagwnl2+Wdfu7FqnHFUpwF5PD/uk2bLu9h3sAZLgXGHrGQV4XAVGncynhbUOmYQDmelZGPGuYOZEtW81/4xx79QNd839vJ1Gz3a18vm9xMtj5Og= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787075251; c=relaxed/simple; bh=MsYKjHS6y/36Y6ge2lZU3+xB8nB3XHivBUckLZVte0o=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=K0OSkJ3tqyPKNkDsk4jrOPJyYYKRfLpRcibQwO6f2/uJZyhgFqjsaW4ya4IAvtai/oSr2sWQxqIuez/93JEFzbHuCnGuqsZBrZmK2X/K7MDuHTl++xb2t4TAbCDtQm8/ODhN6VETxuIIe28CFh2Idt0XsKwiSB7Z728NexzoJ3o= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=gy1PDR6U DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BF2B4BA23D1 Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67IHVikE1016858 for ; Tue, 18 Aug 2026 17:47:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=BhKicWmgHoRNjkiIL2A5fSUT8hN2ah 4PQOGvl067pQA=; b=gy1PDR6UkHrKQIZnUJ/DGkJ8H3FNfP796qiNm5SYRbLUFJ N8njW5dF6LjO0GLqSEBtRSb5b3MqgEdrW2dCewrqE6lGZCrTrF/1yUw+1k3X8Ce2 5aSvelVT2w1SETUvGIRARg3cII7qiUDN4c8kg1Zo3V7GMOAQDrwhpN0hUsg2UXGR qz4l4C/FFoF732AB/R47Bb2R29i5ac4L9Edymc7SCtogKqM1ejTZWio1daID5/Fi UXvQ6sY+MeoNG8KR5k1mRB+ywE6WoG7+UqE1BSFkBQEfpNPhkwDX24AI0eMMVbZE /uE4PNmgfYPrerfLGqUJDhiMUk9fdvFPB8J+9rHQ== Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g2frt9a9p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Aug 2026 17:47:30 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67IHfIO4004086 for ; Tue, 18 Aug 2026 17:47:30 GMT Received: from smtprelay06.dal12v.mail.ibm.com ([172.16.1.8]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g32tw4pmh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Aug 2026 17:47:30 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay06.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67IHlRmS13369892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 18 Aug 2026 17:47:28 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E250A5805D; Tue, 18 Aug 2026 17:47:27 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3B08258052; Tue, 18 Aug 2026 17:47:26 +0000 (GMT) Received: from [9.39.17.245] (unknown [9.39.17.245]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 18 Aug 2026 17:47:25 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------TUiLf70VfX36hJrcL5bBNxns" Message-ID: <9f77ef3d-f40d-4887-9984-2f18447fbadd@linux.ibm.com> Date: Tue, 18 Aug 2026 23:17:24 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHi v1] PowerPC: Create call stubs for compiled modules To: Ulrich Weigand , "gdb-patches@sourceware.org" Cc: Abhay Kandpal , "cel@linux.ibm.com" References: <20260813092829.262470-1-abhay@linux.ibm.com> <1a31198de71abfc8f36c893cc97c81b72c6112a7.camel@de.ibm.com> From: Abhay Kandpal Content-Language: en-GB In-Reply-To: <1a31198de71abfc8f36c893cc97c81b72c6112a7.camel@de.ibm.com> X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=OfaoyBTY c=1 sm=1 tr=0 ts=6a849ab2 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=r77TgQKjGQsHNAKrUKIA:9 a=VnNF1IyMAAAA:8 a=S5IilD1Bkmx3K0OWEZsA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=dHmHGFUygBtWVkLnl2cA:9 a=rq09sMWMFW36m2pC:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwODE4MDEyOSBTYWx0ZWRfX/3cNiS7MJcRn tWekG+5LJ6Wt1bvRfG1wfwf6KkTdtSHbA2LvOlhuPVVCVeAEo+FMRnOdOGhSBTELLP3pJChOAVn lZ7DjYrG4fAW2JJvHiMTkQaFDTfVRWY= X-Proofpoint-GUID: HWyRyytamXQKmATsB98ZCZydoaRW8FBM X-Proofpoint-ORIG-GUID: HWyRyytamXQKmATsB98ZCZydoaRW8FBM X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODE4MDEyOSBTYWx0ZWRfXzoxHABfMFgkN t6wUxLfh+oil8xeP1EraXy8QcYs+jmhXTVrc5V45ThZW6kxxywTkz5NMlXck+atOhff/MUc6Pzr nJZTlOT/BYokyRydDgSk5r2Cn1+rGDFoMZkhuQsLsFsI0i9cyyd9wrdxjolDqjG5mit7GZPP7BL CgdZXYBV7muxYOBrlWNfLoZfsLBBeICo8k1qmnucyqPa7jQtQbtarCVeRHUj5pWga+4Kaan8BeT Nr2gxbkkxS9sUoF88xxUD7HdAydcAdzURv+U2vG5VMUpC/MzEXzllTsZVHVvFtbiNyzyfjP2ctX 144ZX4PUrtv5sM0oBUw4B32UuJaIQZNAtq2WdbBUe/NzQTBdwrJSgZh7zYpjQ5HQu8JSoKdfsbR R+UMcr0guXSqvx4eaIW7wqTIJSNfKfm5EFefD2XJdnhdbYBTcc0u/2FlfvXdDeas0mz5vBhWYdV I1RH5yodvtmFbNQP83A== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-18_03,2026-08-18_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608180129 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org This is a multi-part message in MIME format. --------------TUiLf70VfX36hJrcL5bBNxns Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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        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 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 --------------TUiLf70VfX36hJrcL5bBNxns Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
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
--------------TUiLf70VfX36hJrcL5bBNxns--