From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1292 invoked by alias); 27 Mar 2019 20:38:42 -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 1281 invoked by uid 89); 27 Mar 2019 20:38:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=operated X-HELO: mail-qt1-f193.google.com Return-Path: Subject: Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7) To: Martin Schwidefsky , Mathieu Desnoyers Cc: Paul Burton , Will Deacon , Boqun Feng , Heiko Carstens , Vasily Gorbik , Russell King , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , carlos , Florian Weimer , Joseph Myers , Szabolcs Nagy , libc-alpha , Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Dave Watson , Paul Turner , Rich Felker , linux-kernel , linux-api References: <20190212194253.1951-1-mathieu.desnoyers@efficios.com> <20190212194253.1951-2-mathieu.desnoyers@efficios.com> <5166fbe9-cfe0-8554-abc7-4fc844cf2765@redhat.com> <1965431879.7576.1553529272844.JavaMail.zimbra@efficios.com> <20190327101608.77b0de6f@mschwideX1> From: Carlos O'Donell Message-ID: <4021516e-6a1e-166d-a4f6-e961e6f94cc4@redhat.com> Date: Wed, 27 Mar 2019 20:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <20190327101608.77b0de6f@mschwideX1> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00601.txt.bz2 On 3/27/19 5:16 AM, Martin Schwidefsky wrote: > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT) > Mathieu Desnoyers wrote: > >>>> +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h >> [...] >>>> + >>>> +/* Signature required before each abort handler code. */ >>>> +#define RSEQ_SIG 0x53053053 >>> >>> Why not a s390 specific value here? >> >> s390 also has the abort handler in a __rseq_failure section: >> >> #define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \ >> ".pushsection __rseq_failure, \"ax\"\n\t" \ >> ".long " __rseq_str(RSEQ_SIG) "\n\t" \ >> __rseq_str(label) ":\n\t" \ >> teardown \ >> "j %l[" __rseq_str(abort_label) "]\n\t" \ >> ".popsection\n\t" >> >> Same question applies as powerpc: since disassemblers will try to decode >> that instruction, would it be better to define it as a valid one ? >> >> [...] > > A 4-byte sequence starting with 0x53 is decoded as a "diebr" instruction. > And please replace that "j %l[...]" with a "jg %l[...]", the branch target > range of the "j" instruction is 64K, not enough for the general case. Why was this particular operated selected? So on s390 the RSEQ_SIG will show up as an unexpected "divide to integer" instruction that can't be reached by any control flow? Can we use a NOP with a unique value in an immediate operand? The goal being to have something that won't confuse during a debug session, or that the debugger can ignore (like constant pools on Arm) -- Cheers, Carlos.