From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17541 invoked from network); 19 Aug 2021 13:38:57 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 Aug 2021 13:38:57 -0000 Received: (qmail 3189 invoked by uid 550); 19 Aug 2021 13:38:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3168 invoked from network); 19 Aug 2021 13:38:54 -0000 Date: Thu, 19 Aug 2021 09:38:41 -0400 From: Rich Felker To: Florian Weimer Cc: Olivier Galibert , musl@lists.openwall.com Message-ID: <20210819133841.GP13220@brightrain.aerifal.cx> References: <20210818225222.81919-1-galibert@pobox.com> <20210819004903.GN13220@brightrain.aerifal.cx> <878s0y2d4r.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878s0y2d4r.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH] arm64/sigcontext: Synchronize the type of the __reserved field with the linux kernel. On Thu, Aug 19, 2021 at 07:54:12AM +0200, Florian Weimer wrote: > * Rich Felker: > > > On Thu, Aug 19, 2021 at 12:52:23AM +0200, Olivier Galibert wrote: > >> clang's compiler-rt sanitizer_linux.cpp expects the __reserved field > >> to be convertible to u8 *. So let's. > >> --- > >> arch/aarch64/bits/signal.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/aarch64/bits/signal.h b/arch/aarch64/bits/signal.h > >> index 5098c734..a46997e3 100644 > >> --- a/arch/aarch64/bits/signal.h > >> +++ b/arch/aarch64/bits/signal.h > >> @@ -19,7 +19,7 @@ typedef struct sigcontext { > >> unsigned long fault_address; > >> unsigned long regs[31]; > >> unsigned long sp, pc, pstate; > >> - long double __reserved[256]; > >> + unsigned char __reserved[4096] __attribute__((__aligned__(16))); > >> } mcontext_t; > >> > >> #define FPSIMD_MAGIC 0x46508001 > > > > The member name __reserved is not API, much less its particular type. > > The name is called __reserved, but it is actually part of the API. > We learned this when we tried to rename it: > > > > The name and its __ prefix are rather unfortunate, but we are stuck with > it. I question the reasoning there. Just because there are users of it doesn't mean it's API, *especially* if the users are things like sanitizer lib that regularly poke at internals that are not interface contracts. Use of a name like __reserved as API is *really* bad since it could even be something like a macro for an attribute in the implementation, rather than something available as a member name. My interpretation was that it's something like the powerpc reserved space where there's a separate pointer into it, which you're supposed to access it by. But that doesn't seem to be the case here, so I'm not sure what the right way to access it is. Do you have a list of software that's actually poking at it so we can evaluate the situation better for figuring out what to do? Rich