From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76724 invoked by alias); 25 Jan 2017 12:31:37 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 76684 invoked by uid 89); 25 Jan 2017 12:31:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Freddie, freddie, Chopin, H*i:sk:1485251 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 12:31:35 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 279E0C05AA6B for ; Wed, 25 Jan 2017 12:31:35 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PCVYS7027419 for ; Wed, 25 Jan 2017 07:31:34 -0500 Received: by calimero.vinschen.de (Postfix, from userid 500) id 37588A80CD7; Wed, 25 Jan 2017 13:31:33 +0100 (CET) Date: Wed, 25 Jan 2017 12:31:00 -0000 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted Message-ID: <20170125123133.GE21591@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <1484238035.1122.3.camel@op.pl> <62aaa2d2-f8f7-4c00-7954-f62b47a798b4@foss.arm.com> <2fb85b24-a2e6-4e8b-1a2c-11faeb01d33d@foss.arm.com> <1484330715.2096.1.camel@op.pl> <51d83e39-7d6d-90f1-b61b-5a5af0a0825e@foss.arm.com> <4f0be40a-dd11-7d83-690b-717e832b45d2@foss.arm.com> <1485251898.10926.3.camel@op.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dzs2zDY0zgkG72+7" Content-Disposition: inline In-Reply-To: <1485251898.10926.3.camel@op.pl> User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2017/txt/msg00088.txt.bz2 --Dzs2zDY0zgkG72+7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1382 On Jan 24 10:58, Freddie Chopin wrote: > On Fri, 2017-01-20 at 13:37 +0000, Thomas Preudhomme wrote: > > Have you had time to work on the last version of the patch? >=20 > OK, I finally got down to it. >=20 > The toolchain builds, but this is obvious. >=20 > Some of the locks are not always needed: >=20 > 1. dd_hash_lock from posix/telldir.c is defined only if HAVE_DD_LOCK is > defined. It seems that only linux and phoenix define that macro, but it > would be OK to have this lock conditional. >=20 > 2. __sfp_lock and __sinit_lock from stdio/findfp.c,=C2=A0__tz_lock_object > from time/tzlock.c, __malloc_lock_object from stdlib/mlock.c and > __env_lock_object from stdlib/envlock.c are defined only when > __SINGLE_THREAD__ is _NOT_ defined. However __atexit_lock in > stdlib/__call_atexit.c is defined in case of __SINGLE_THREAD__ > configuration, but it is not used, as all uses are conditional anyway. > On the other hand dd_hash_lock and atexit_mutex are not protected with > that macro. Maybe all locks should be conditional on this macro? I have > no idea where does this macro come from, as grepping for it in newlib, > gcc or binutils gives no definition... Maybe this is some obsolete > macro which can be just removed? __SINGLE_THREAD__ gets set with --enable-newlib-multithread=3Dno, see configure.host. Corinna --=20 Corinna Vinschen Cygwin Maintainer Red Hat --Dzs2zDY0zgkG72+7 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYiJqlAAoJEPU2Bp2uRE+ghxYP/jdkJ7K+BuuHPKEQR24hqyW2 k8YLitq54G2HeBcYt0SUk4WwIt5q4myo8L550Kmo8SNKoTmraIa5pbavWxH80op2 +aleOIf5raWaKZsv9wdIyv8EZIbjrKnp772TuwVCzV5KXtkFQ7vVDv7FuK5mWTzb MT6GgNAJ9SU+1HSUGGBQTPw06NZ4CZZeM4grjt5GflPSGJP/SbxflafvFSv+Byrg 8pVNw5gF9Lnl2bZXuVHoqLY7VEiv8GWNf/RjxQiqbDKn/8q7QFzFOWxtytgU898D Jekhby1B7S/B+bMPTAS1eKGSzaNXePSfXenJL9f+HGS1JWcALg9BUY6/83lj/fKd SMqxM/JB3iGKPVr94YaPAFWgh9q9zsyZy4s9qp22K2x7oAU1wP/a4K7WhTd18LFB b2MxJNnhoE4oLQ1uzUdajnovTedetMJoqoiaLkHXqvpgTPPwgJTFRVotDuHlhmTS F4DwBj3lAFND/8nOlNfY7bsHr1+BlPPE8Iu18SkoMXHVvVrcBbHiTXvJtNchrwmv t9bMvB1oT0gWxTiXoz6q03k8RKUh7GpV9cQjKnQXU1pi38bzmyZpbX6edntO8mDw fdklgGpEED98hP+BIZ6Vprs0oJ4IIuRO4/dr4WuyWkNJg4gBpSS50ziEVc6oyFsw fz1IJ69XwT7kyz0T1gk2 =wFYQ -----END PGP SIGNATURE----- --Dzs2zDY0zgkG72+7--