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=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 cdecd2f3 for ; Fri, 24 Jan 2020 02:10:23 +0000 (UTC) Received: (qmail 22424 invoked by uid 550); 24 Jan 2020 02:10:21 -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 22406 invoked from network); 24 Jan 2020 02:10:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3ejK6lZeVRAKvxqppFmiQImc+uiprMmHnpK8rEHgA0U=; b=gdz2AZkE037F/6E2V34J2RW18tHlf0xOUF6RzLbtYIT5jUnLoNgzso5hLws64DAUDv 9Qoy25RpiA60SgEamHg37y2XoPVSLIhdKJq0cUzmitTvrshJgb/xJAiheVhlKlDPYC5A g7wFn1cB63rk2XxLvmChYTRiWXCzMtP8S2m5/NApq942Z7GmNVKkNnB5fwF041JwiEwG d6KLVWu499ffhOXFiGPQPAV4ea/CRK1o+bT7c+8dJk4dabSU5PaHoYxJj4IxH/U4gDZX FMNgtwNXb/sKRagcnhaT9fYS/L8ybYOo/+XFlfhB2kgMZKQDrSgYeSF1rZFgY5/jhzBF aviQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3ejK6lZeVRAKvxqppFmiQImc+uiprMmHnpK8rEHgA0U=; b=r2z00loEWC5RkPi7UjQHbr4+7dnbMWxMiR0Iezam0gHmCrAg76Cj7Jx6zoAo5YkyRF JWphkzjXMkE1bt0FxJ0ASgTn2uL57rRhRQNvX/gAk6e+VQBIL0VEz9XGteGLunLXs45k 42Pv82OMdm0sHYwNdoCWOPBI4tsQ5Lb1hfMOO73dJJi7hQE4XH7vTb9xNM5MfhJRg0de JB6MxnYYUdyUK8/Gpz4WKgI8gHO+Qrcc3VWsyFIM7UVMzuGgh+36OMQn0lSLKYKGl7v3 RtMsRHB/cFlWl22flOUbTDt4U9a4KjeY/kI6I5tvpbYFktDJjZQq9KXsTA/Xc2OS+tk0 UxfQ== X-Gm-Message-State: APjAAAWVs11YKcazflYtLiZtUZx1ym2kxXhngLSwrA3hd6nIjbdk8Cus 9Uu6trMMtPKXbDEjiL4zGuzGcoJTdEst7VnKdGZWJvEa X-Google-Smtp-Source: APXvYqx3JTZssAk8MR/Wa64MyqP1MaKMoLVNqjAwsMQMGzvXGG1K+qJdy6FZC7CIVuvjXVrnU8a0rjFAs4ybz90a084= X-Received: by 2002:ab0:3387:: with SMTP id y7mr550477uap.99.1579831808854; Thu, 23 Jan 2020 18:10:08 -0800 (PST) MIME-Version: 1.0 References: <20200123041812.GL30412@brightrain.aerifal.cx> In-Reply-To: <20200123041812.GL30412@brightrain.aerifal.cx> From: Andre McCurdy Date: Thu, 23 Jan 2020 18:09:57 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] arm __a_barrier_v6 register value should be zero? On Wed, Jan 22, 2020 at 8:18 PM Rich Felker wrote: > On Wed, Jan 22, 2020 at 05:30:53PM -0800, Andre McCurdy wrote: > > The arm1176jzfs documentation describing the armv6 CP15 Data Memory > > Barrier operation seems to specify the register value written to the > > coprocessor as "SBZ" ie Should Be Zero. See page 216 of: > > > > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf > > > > However the __a_barrier_v6() function which implements this in musl > > uses r0 as the register written to the coprocessor and doesn't > > initialise it. Should __a_barrier_v6() set r0 to 0 before issuing the > > mcr instruction? Or is it defined somewhere that this register value > > doesn't matter? > > __a_barrier_* have a contract not to clobber r0 -- see the calling > code in arch/arm/atomic_arch.h: > > static inline void a_barrier() > { > register uintptr_t ip __asm__("ip") = __a_barrier_ptr; > __asm__ __volatile__( BLX " ip" : "+r"(ip) : : "memory", "cc", "lr" ); > } > > We could probably switch to using ip as the register if needed. > However looking at Linux kernel source, no effort is made to zero the > register used (see arch/arm/include/asm/assembler.h for the definition > of the smp_dmb macro) so I think it must not actually matter... > > Nice find, though. Let's see if we can get a better authoritative > answer on it. OK. Another question: what's the reason for testing that the 3rd char of AT_PLATFORM isn't [0-9] in __set_thread_area()? Isn't just testing that the first two chars are "v6" enough to confirm armv6?