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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 21025 invoked from network); 18 Dec 2020 19:39:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2020 19:39:05 -0000 Received: (qmail 15599 invoked by uid 550); 18 Dec 2020 19:39:02 -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 15581 invoked from network); 18 Dec 2020 19:39:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1608320330; bh=BRHL1/3B54sB56RYz0hYUrstlY/yF4biEgDBvxnIoMU=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=gdTD7H6gRyfTXRorFmekDEiU1QOIV5wLWKJgsX0inkibxG0WUbiCHl/BFW7NEDMTj LRhBvXMUpdOC9e1XsizcWjR9HO0BF9aZDxfkvcH7tQtK57y1utJlp+2KhIjLfe4DeL xTUnrrey5bnrRo1HDwvthGVEyMBogOui7EucqODI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Fri, 18 Dec 2020 20:38:49 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20201218193849.GA7530@voyager> References: <20201217002348.GO534@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201217002348.GO534@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:Nw4jiWDKUt7oB0zpqnkvfOWCDTJ+zxbe+kUvdD+B+nBIXR1wWYb TVOngmpInFCu0N+xSxbXjeb+n0jxRNoUVAo6M0B3d083p9Ffk0NH6YUNneISDh5C8eikS4c 6OHWCscm72ON7FqFJ1jh2ddKFcjDk3pmUWMIn31c87wxxSqhTdQnQUiHuZ0sbwXG5EZP9tL koI2r2xFC9Cp8Af1FAq7A== X-UI-Out-Filterresults: notjunk:1;V03:K0:23mvUibw3Lc=:kTtyO9YHqBwO6yWvxzF9HQ LQJ4lwwK04xmTyvxzRtCyiRlsOboLrUkDoer2S6P4xlO9lT+K3ekNZY4cXH7COgjTIzmqRi1z Yjx7y/reyRLWaPuawIbif9C1vWBNHO8Pg1582wIbyW76GZ5TSchhV6LMBvPlcFTYPCKwSfDP1 OILEE8EgO2JUSdK+pbXk4WsjQKRFAoYmPHi01yiTeVtJuyOjEDtCtcBqMWqu/84NEd7xfky57 8fbgxEvJ0g+4AaCa/w7TILOMkJpsWTvURkBXpNzScyxjIpNGcT1W5P0pu1/Maaf9hPhgCCe/S oci1TkeRWNxm6TvuL5CvwCB7JYww0YyvCrHodUOEr+mulsuusW45u+MVbFPQyzQO530RsAtbQ +DBhb/BvUg3uIN6jCCpv4FzJrmOlMgXgBL4QFtUEb5J4ia9ZCtxB3n3e4kMsvkTtAcsSDQXEN jdFn5Ba/dEBedXnHOKb3R7gBBxq25UErFOdQ3GDEBBXnyorKY3clWqwKYR30OtWSZ0Vxe6fzU Inx0LycGlZXYcNqPkZkXkUN7hwh0oVl3d5QezGBfJIWJb3FnxVoFj0vzJZFkCaTB7ECXqa7JP 9cwAgHpMlvJ6T0d6TFMhJbUy0wRpgDVf94M43QofjfW1zT7IugYdmZ/ykSMrifWrlrzNXowo8 OYH8klMoKdne5Isg2ncADLTBPEhAxCmHbHBCTJ3yD0ZN0gC6kSK1gGGCalTtIJYTnMOQ+kzft IL9CC9ndZiDBKZKKG1cCa3Qgo0GmmF16cWS+lwTtwToudw+FXYnHnApnMV+bW001A4LBLY+VM q3cM77ZulBa36bee1Lrx+Hn33WAUmwlbyTSK5IkOMQCc0+XPmO49zquDAxH1YzQLTX7V8Q8cB QjSCdZrAypmJfr5iIzvQ== Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Musl on Cortex-M Devices On Wed, Dec 16, 2020 at 07:23:49PM -0500, Rich Felker wrote: > On Wed, Dec 16, 2020 at 06:43:15PM -0500, Jesse DeGuire wrote: > > diff --git a/src/thread/arm/__unmapself.s b/src/thread/arm/__unmapself= .s > > index 29c2d07b..fe0406e3 100644 > > --- a/src/thread/arm/__unmapself.s > > +++ b/src/thread/arm/__unmapself.s > > @@ -3,7 +3,7 @@ > > .global __unmapself > > .type __unmapself,%function > > __unmapself: > > - mov r7,#91 > > + movs r7,#91 > > svc 0 > > - mov r7,#1 > > + movs r7,#1 > > svc 0 > > OK, but this file can't be used on nommu anyway. Instead the generic C > version has to be used. > Speaking of that (C) version, maybe someone should note down somewhere that it is only safe to call if simultaneous calls from other threads are precluded somehow. That function uses global variables, so if multiple threads call it at the same time, there will be blood (well, there will be clobbering in any case). Which is fulfilled at the moment: The only call site of __unmapself() is pthread_exit(), after getting the thread list lock. That is a global lock, so further threads also exitting would have to queue up there. But I think it is rather non-intuitive that the thread-list lock happens to also protect the global variables in __unmapself.c. And that is a property of the C version not shared by the assembler versions, which are all thread-safe. Also, why can't this be used on nommu? I thought the only differences between nommu and mmu were that you can't call mmap() except for MAP_ANON, and you can't call fork(). This merely runs munmap() on a MAP_ANON region, and exit(), and so does the C version, except the C version sets up its own stack to do so, in order to not saw off the branch it is sitting on. What am I missing? Ciao, Markus