From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BhYqEdbmsmpjODQAWB0awg (envelope-from ) for ; Tue, 22 Sep 2026 16:36:38 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=WywnaDUz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2A6E11E06B; Tue, 22 Sep 2026 16:36:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 4FF901E01F for ; Tue, 22 Sep 2026 16:36:37 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 764BE4BB1C16 for ; Tue, 22 Sep 2026 20:36:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 764BE4BB1C16 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=WywnaDUz Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id F147D4B99F5E for ; Tue, 22 Sep 2026 20:36:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F147D4B99F5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F147D4B99F5E Authentication-Results: sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790109372; cv=none; b=goLAxqoSaHYGffKRw0bBKq+cs1jvm/1k/CcIuWbbVKzgHU8izaz8c3XhZQq45Zmtn7vfNJ486Lkkmvji/t7NIuXsjK4VIW/fKVrCAW17azV02mnkkCf0I19orU5WuoWxRgfGYvykXWrH4e54V4N+LBxVnrNNtZFYmEN9vchM/rc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790109372; c=relaxed/simple; bh=5TZ6lHTtyxxAnmD5atky38FJtkB6Jjbg31cKJSwFbUU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=I1iEbEvdZzOkedPuoUwsI2E/5VdRcE8XEMPa0ExNnjvC/iv/Wlv+jSgxStw7bh4ZYY9WbftdGuMGuXH+gvDv/7wEdktKrdWoq14hdeuAKL6HrcXAj/58GfaTPWfpXdDUJH6opYZsHWFLPpV+O4HfdHsbAw6oxhYnTGy3qTgoIqA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=WywnaDUz DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F147D4B99F5E Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 68MKa0VQ069009 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Sep 2026 16:36:05 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 68MKa0VQ069009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1790109366; bh=GWEPJpw7un1NYdj9nXemTa7BnzSCL4LIlg3jhKE72LA=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=WywnaDUz7JX3qF5lR6B/fKuhdpmzJWpsbYrrfw+d6ZVxYOafB33SpM0i4ImgCWPan 8Kgc4csPAcffO1Os13hFg0W6mUMRP57ZLZIDjYPdmvHPQY4y+LnUuK5JrBZV48OoNu e23rPV17CXYFmk6KI3ZN+CaHRgN4LaHQreHYJ28TOLStwY3AYoEHFIKBg1Ix5iN8bI BeZsv0ixvwgFT5Pq744puTTkoST+iSFUG79DVS7sT3ZUGjWva7CreaOH7S4HwegXM3 RA/OaRwrIS0R+r0hEsm4KOh7vn5HhQUzbEQJDkU2tM3oluvj5ZcSmbd7kM13Lgi0jx /zKLFC7VHch0w== Received: by simark.ca (Postfix) id A3C641E01F; Tue, 22 Sep 2026 16:35:59 -0400 (EDT) Message-ID: <7a92afdb-8e4d-4e41-b12e-3cb2f5505e43@polymtl.ca> Date: Tue, 22 Sep 2026 16:35:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] Remove stale pre-AIX-7.2 compatibility guards To: Aditya Vidyadhar Kamath , ulrich.weigand@de.ibm.com, tom@tromey.com Cc: gdb-patches@sourceware.org, Aditya.Kamath1@ibm.com, sangamesh.swamy@in.ibm.com References: <20260922045230.58748-2-akamath996@gmail.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260922045230.58748-2-akamath996@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 22 Sep 2026 20:36:00 +0000 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 On 9/22/26 12:52 AM, Aditya Vidyadhar Kamath wrote: > From: Aditya Kamath > > GDB now requires AIX 7.2 as the minimum supported version and will > support AIX 7.2 TL5, AIX 7.3 and upcoming AIX releases. Remove > dead compatibility code that existed only for older releases. > > Remove the HAVE_DECL_GETTHRDS configure check since aix-thread.c was the last > user of that macro. Merge ptrace64aix and ptrace32 into a single > ptrace_aix function since they became identical after this > cleanup, and collapse all call sites that branched on arch64 just to > pick between the two. Also clean up rs6000-aix-nat.c by removing the > ARCH3264 and HAVE_PTRACE64 guards along with the ptracex fallback in > rs6000_ptrace32 and rs6000_ptrace64, which are now simple wrappers > around ptrace64. > > Also as per https://www.ibm.com/docs/en/aix/7.2.0?topic=p-ptrace-ptracex-ptrace64-subroutine > ptrace64 will also support 32-bit debugees. > > In store_regs_user_thread we use ppc_vsr0_upper_regnum when checking validity > and collecting the VSX upper-doubleword registers. > > In store_regs_user_thread guard ctx.fpscr with ppc_fpscr_regnum instead of ppc_xer_regnum, and > add the ppc_fpscr_regnum >= 0 check to match the 64-bit path. > Use ppc_num_gprs instead of ppc_num_fprs in the GPR regno range check. Sorry, I missed that last bit when reading the first time. Are those changed related to removing stale pre-AIX 7.2 code? Or are they fixes on their own? If it's the latter, that should be a separate patch. I also forgot, but I asked Claude to review this patch, it raised some good points. There is this one that sounds important, but I have no way of checking if it's true: - The 32-bit SPR fix is only half done. If the GPR layout problem is being fixed in pdc_read_regs, the SPRs have the same problem. memcpy (&context->msr, &sprs32, sizeof (sprs32)) (gdb/aix-thread.c:449) copies a struct ptsprs (32-bit fields) over the 64-bit fields of pthdb_context_t, and consumers read them field by field (supply_sprs32 (regcache, ctx.iar, ctx.msr, ...) at gdb/aix-thread.c:1236). pdc_write_regs has the reverse problem: it passes &context->msr to PTT_WRITE_SPRS for a 32-bit inferior (gdb/aix-thread.c:517). Either fix both in the same (separate) commit as the GPRs, or leave it all for later, but don't do only half. It also pointed out that there is a use of HAVE_PTRACE64 that can be removed in nat/gdb_ptrace.h. I wrote some more inline below. > @@ -470,14 +437,14 @@ pdc_read_regs (pthdb_user_t user_current_pid, > { > if (data->arch64) > { > - if (!ptrace64aix (PTT_READ_SPRS, tid, > + if (!ptraceaix (PTT_READ_SPRS, tid, > (unsigned long) &sprs64, 0, NULL)) The indent needs to be adjusted here. > @@ -1357,14 +1286,14 @@ fetch_regs_kernel_thread (struct regcache *regcache, int regno, > { > if (data->arch64) > { > - if (!ptrace64aix (PTT_READ_GPRS, tid, > + if (!ptraceaix (PTT_READ_GPRS, tid, > (unsigned long) gprs64, 0, NULL)) Indent needs to be fixed. > @@ -1377,9 +1306,9 @@ fetch_regs_kernel_thread (struct regcache *regcache, int regno, > int ret = 0; > __vmx_context_t vmx; > if (data->arch64) > - ret = ptrace64aix (PTT_READ_VEC, tid, (long long) &vmx, 0, 0); > + ret = ptraceaix (PTT_READ_VEC, tid, (long long) &vmx, 0, 0); > else > - ret = ptrace32 (PTT_READ_VEC, tid, (uintptr_t) &vmx, 0, 0); > + ret = ptraceaix (PTT_READ_VEC, tid, (uintptr_t) &vmx, 0, 0); Do we still need two separate ptraceaix calls here? > @@ -1394,9 +1323,9 @@ fetch_regs_kernel_thread (struct regcache *regcache, int regno, > __vsx_context_t vsx; > int ret = 0; > if (data->arch64) > - ret = ptrace64aix (PTT_READ_VSX, tid, (long long) &vsx, 0, 0); > + ret = ptraceaix (PTT_READ_VSX, tid, (long long) &vsx, 0, 0); > else > - ret = ptrace32 (PTT_READ_VSX, tid, (long long) &vsx, 0, 0); > + ret = ptraceaix (PTT_READ_VSX, tid, (uintptr_t) &vsx, 0, 0); And here? > @@ -1421,7 +1350,7 @@ fetch_regs_kernel_thread (struct regcache *regcache, int regno, > { > if (data->arch64) > { > - if (!ptrace64aix (PTT_READ_SPRS, tid, > + if (!ptraceaix (PTT_READ_SPRS, tid, > (unsigned long) &sprs64, 0, NULL)) Indent. > @@ -1678,9 +1607,9 @@ store_regs_user_thread (const struct regcache *regcache, pthdb_pthread_t pdtid) > { > memset(&vsx, 0, sizeof(__vsx_context_t)); > for (i = 0; i < ppc_num_vshrs; i++) > - if (REG_VALID == regcache->get_register_status (tdep->ppc_vsr0_regnum + i)) > + if (REG_VALID == regcache->get_register_status (tdep->ppc_vsr0_upper_regnum + i)) This line is now too long. > @@ -1869,16 +1781,16 @@ store_regs_kernel_thread (const struct regcache *regcache, int regno, > if (__power_vmx()) > { > if (data->arch64) > - ret = ptrace64aix (PTT_READ_VEC, tid, (long long) &vmx, 0, 0); > + ret = ptraceaix (PTT_READ_VEC, tid, (long long) &vmx, 0, 0); > else > - ret = ptrace32 (PTT_READ_VEC, tid, (long long) &vmx, 0, 0); > + ret = ptraceaix (PTT_READ_VEC, tid, (uintptr_t) &vmx, 0, 0); And here? > @@ -246,42 +231,20 @@ regmap (struct gdbarch *gdbarch, int regno, int *isfloat) > return -1; > } > > -/* Call ptrace(REQ, ID, ADDR, DATA, BUF). */ > +/* Call ptrace64(REQ, ID, ADDR, DATA, BUF). */ > > static int > rs6000_ptrace32 (int req, int id, int *addr, int data, int *buf) > { > -#ifdef HAVE_PTRACE64 > - int ret = ptrace64 (req, id, (uintptr_t) addr, data, buf); > -#else > - int ret = ptrace (req, id, (int *)addr, data, buf); > -#endif > -#if 0 > - printf ("rs6000_ptrace32 (%d, %d, 0x%x, %08x, 0x%x) = 0x%x\n", > - req, id, (unsigned int)addr, data, (unsigned int)buf, ret); > -#endif > - return ret; > + return ptrace64 (req, id, (uintptr_t) addr, data, buf); > } Can the rs6000_ptrace32 and rs6000_ptrace64 wrappers be removed? Simon