Date: Wed, 23 Mar 2022 15:16:36 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Jessica Clarke <jrtc27@freebsd.org>, Andrew Turner <andrew@FreeBSD.org> Cc: "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org> Subject: Re: git: 6713be315900 - main - Add NT_ARM_ADDR_MASK Message-ID: <e41417dd-5446-e5d6-9bd1-0830398d410b@FreeBSD.org> In-Reply-To: <2C1219E1-9F36-4FDC-95B1-AD6DC9F0C215@freebsd.org> References: <202202221727.21MHR4dv022628@gitrepo.freebsd.org> <2C1219E1-9F36-4FDC-95B1-AD6DC9F0C215@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/22/22 9:59 AM, Jessica Clarke wrote: > On 22 Feb 2022, at 17:27, Andrew Turner <andrew@FreeBSD.org> wrote: >> >> The branch main has been updated by andrew: >> >> URL: https://cgit.FreeBSD.org/src/commit/?id=6713be3159000783f7aacf3ea90d6c6878c44da0 >> >> commit 6713be3159000783f7aacf3ea90d6c6878c44da0 >> Author: Andrew Turner <andrew@FreeBSD.org> >> AuthorDate: 2021-08-30 16:43:22 +0000 >> Commit: Andrew Turner <andrew@FreeBSD.org> >> CommitDate: 2022-02-22 17:10:35 +0000 >> >> Add NT_ARM_ADDR_MASK >> >> This can be used by debuggers to find which bits in a virtual address >> should be masked off to get a canonical address. This is currently used >> by the Pointer Authentication Code support to get its mask. It could also >> be used if we support Top Byte Ignore for the same purpose. >> >> Reviewed by: kib >> Sponsored by: The FreeBSD Foundation >> Differential Revision: https://reviews.freebsd.org/D34302 > > This definition seems backwards? In Linux it’s NT_ARM_PAC_MASK, i.e. > the mask for the PAC bits, but you’ve called it NT_ARM_ADDR_MASK here, > which sounds like the mask you apply to get the address bits, but it’s > not, you apply the negation of this mask to get the address bits. In that sense, it's identical to NT_ARM_PAC_MASK on Linux (same actual contents and layout). Given that, using a different name seems gratuitous vs reusing the existing name as we did for NT_X86_XSTATE, NT_ARM_VFP, NT_PPC_VMX, NT_ARM_TLS, etc. If the content of the note was different, then a different name might be warranted, but if the content and purpose of the note are the same, then it's not clear why we need a different name for the constant. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e41417dd-5446-e5d6-9bd1-0830398d410b>