From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 6e7bb2da for ; Sun, 19 Jan 2020 17:19:22 +0000 (UTC) Received: (qmail 30003 invoked by uid 550); 19 Jan 2020 17:19:20 -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 29983 invoked from network); 19 Jan 2020 17:19:20 -0000 Date: Sun, 19 Jan 2020 12:19:08 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200119171908.GG30412@brightrain.aerifal.cx> References: <20200119110743.GD2020@voyager> <20200119113134.GJ23985@port70.net> <8299f261-7870-57a6-37cf-d4ce482ad81e@openwall.com> <20200119161851.GC30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Minor style patch to exit.c On Sun, Jan 19, 2020 at 08:11:37PM +0300, Alexander Monakov wrote: > > > On Sun, 19 Jan 2020, Rich Felker wrote: > > > Conceptually the _start is an array; that means it's fine to iterate > > over its elements, and we could even do so with the "correct" type. > > The problem is that _end is a different symbol and thereby inherently > > a "different object", and comparing against it with < is not valid; > > the compiler can legitimately optimize that out. I think with != would > > be valid, but I'm not sure we can trust compilers to honor any > > consistency for such "one past the end" comparisons. Casting to > > (uintptr_t) before doing the != comparison would absolutely be safe in > > the abstract machine; whether compilers honor this is unclear (because > > of the "provenance" stuff, which could break even the current code, so > > arguably we should have some "provenance barrier" here). > > > > Of course exit runs the array in reverse, which makes it even more of > > a mess. _end[-1] is clearly not valid when _end is an array object, > > and the compiler is free to break that. > > I would suggest > > void (**ptr)(void); > > __asm__ ("" : "=g"(ptr) : "0"(..._end), "X"(..._start)); > > while (ptr != _start) (*--ptr)(); I think we could just put the assignment outside the asm and use "+g". Not clear why _start is needed as an input operand. It's external so asm must be assumed to be able to see it. BTW does the "X" constraint work all the way back to ancient gcc (and then presumably with pcc, clang)? The first time I ever saw it was in one of your other patches. Rich