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 4546 invoked from network); 20 Aug 2021 06:46:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Aug 2021 06:46:17 -0000 Received: (qmail 22118 invoked by uid 550); 20 Aug 2021 06:46:14 -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 22100 invoked from network); 20 Aug 2021 06:46:14 -0000 Date: Fri, 20 Aug 2021 08:46:02 +0200 From: Szabolcs Nagy To: Rich Felker Cc: Florian Weimer , Olivier Galibert , musl@lists.openwall.com Message-ID: <20210820064602.GJ37904@port70.net> Mail-Followup-To: Rich Felker , Florian Weimer , Olivier Galibert , musl@lists.openwall.com References: <20210818225222.81919-1-galibert@pobox.com> <20210819004903.GN13220@brightrain.aerifal.cx> <878s0y2d4r.fsf@oldenburg.str.redhat.com> <20210819133841.GP13220@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210819133841.GP13220@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH] arm64/sigcontext: Synchronize the type of the __reserved field with the linux kernel. * Rich Felker [2021-08-19 09:38:41 -0400]: > 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? __reserved holds sigcontext extensions so i'd expect code accessing the extended register state from a signal handler would use it (includes fp/simd regs). e.g. chromium tests seem to use it: https://source.chromium.org/search?q=uc_mcontext.__reserved but the ucontext access code in breakpad is written in asm so the c struct is not used in actual code. qemu seems to define its own types. and i don't immediately know of other tools that poke at sigcontext.