From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70311 invoked by alias); 17 Apr 2019 16:17:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 70224 invoked by uid 89); 17 Apr 2019 16:17:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: relay1.mentorg.com Date: Wed, 17 Apr 2019 17:08:00 -0000 From: Joseph Myers To: Mathieu Desnoyers CC: carlos , Will Deacon , Florian Weimer , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api Subject: Re: [PATCH 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v8) In-Reply-To: <364803063.586.1555516769056.JavaMail.zimbra@efficios.com> Message-ID: References: <20190416173216.9028-1-mathieu.desnoyers@efficios.com> <20190416173216.9028-2-mathieu.desnoyers@efficios.com> <364803063.586.1555516769056.JavaMail.zimbra@efficios.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2019-04/txt/msg00409.txt.bz2 On Wed, 17 Apr 2019, Mathieu Desnoyers wrote: > > +/* RSEQ_SIG is a signature required before each abort handler code. > > + > > + It is a 32-bit value that maps to actual architecture code compiled > > + into applications and libraries. It needs to be defined for each > > + architecture. When choosing this value, it needs to be taken into > > + account that generating invalid instructions may have ill effects on > > + tools like objdump, and may also have impact on the CPU speculative > > + execution efficiency in some cases. */ > > + > > +#define RSEQ_SIG 0xd428bc00 /* BRK #0x45E0. */ > > After further investigation, we should probably do the following > to handle compiling with -mbig-endian on aarch64, which generates > binaries with mixed code vs data endianness (little endian code, > big endian data): First, the comment on RSEQ_SIG should specify whether it is to be interpreted in the code or the data endianness. > For ARM32, the situation is a bit more complex. Only armv6+ > generates mixed-endianness code vs data with -mbig-endian. > Prior to armv6, the code and data endianness matches. Therefore, > I plan to #ifdef the reversed endianness handling with: > > #if __ARM_ARCH >= 6 && __ARM_BIG_ENDIAN > > on arm32. That doesn't work well because BE code (.o files) can be built for v5te (for example) and used on a range of different architecture variants with both BE32 and BE8 - the choice between BE32 and BE8 is a link-time choice, not a compile-time choice. So if the value for Arm is a compile-time constant, it should also work for both BE32 and BE8. In turn, that suggests to me that RSEQ_SIG should be defined to be a value that is always in the code endianness (and whatever corresponding kernel code handles RSEQ_SIG values should act accordingly on architectures where the two endiannesses can differ). If the kernel ABI is already fixed in a way that prevents such a definition of RSEQ_SIG semantics as using code endianness, a value should be chosen for Arm that works for both endiannesses. (Also, installed glibc headers are supposed to work with older compilers, and support for __ARM_ARCH was only added in GCC 4.8. Before that you need to test lots of separate macros for different architecture variants to determine a version number.) -- Joseph S. Myers joseph@codesourcery.com