From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93179 invoked by alias); 20 Jan 2017 13:55:29 -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 93058 invoked by uid 89); 20 Jan 2017 13:55:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: smtpo49.poczta.onet.pl Received: from smtpo49.poczta.onet.pl (HELO smtpo49.poczta.onet.pl) (213.180.142.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Jan 2017 13:55:16 +0000 Received: from [192.168.2.253] (83-238-239-138.adsl.inetia.pl [83.238.239.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freddie_chopin@op.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 3v4hzf3MFTzStsj4v; Fri, 20 Jan 2017 14:55:09 +0100 (CET) Message-ID: <1484920509.1316.7.camel@op.pl> Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted From: Freddie Chopin To: Thomas Preudhomme , newlib@sourceware.org Date: Fri, 20 Jan 2017 13:55:00 -0000 In-Reply-To: <4f0be40a-dd11-7d83-690b-717e832b45d2@foss.arm.com> References: <34e2c2ad-be0f-44ed-201e-a6f294814f4e@foss.arm.com> <5851557A.4080707@embedded-brains.de> <800fa569-cd83-bd61-95e3-7ad83e053d6c@foss.arm.com> <4409ff03-7c2f-550d-a57a-6b6503bd5933@foss.arm.com> <1483987769.1304.2.camel@op.pl> <6e978ca7-e90e-5fa9-84c4-19c24a993e4a@foss.arm.com> <1484068006.1266.1.camel@op.pl> <89891529-77aa-48af-50bf-aede537a5f1d@LGSInnovations.com> <37230278-6fc6-b0f0-6254-c6e6882f5a99@foss.arm.com> <1484162070.1261.1.camel@op.pl> <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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00074.txt.bz2 On Fri, 2017-01-20 at 13:37 +0000, Thomas Preudhomme wrote: > Hi Freddie, > > Have you had time to work on the last version of the patch? Hi Thomas! I did not hae time this week to try it again - I've planned to do that on the weekend. But from what I've seen the only difference between the new version and the one I tested last week is the addition of 4 missing lock objects. I think that the patch will work, but - as I've said - I'll compile the toolchain on the weekend and give it a try (; BTW - maybe it would be possible to make the names of the locks consistent (in a separate patch)? Internally this changes nothing for newlib, but for this particular patch it would be nice to have names like this: +struct _lock _lock___sinit_recursive_lock; +struct _lock _lock___sfp_recursive_lock; +struct _lock _lock___atexit_recursive_lock; +struct _lock _lock___quick_exit_lock; +struct _lock _lock___malloc_recursive_lock; +struct _lock _lock___env_recursive_lock; +struct _lock _lock___tz_lock; +struct _lock _lock___dd_hash_lock; instead of this: struct _lock _lock___sinit_lock; struct _lock _lock___sfp_lock; struct _lock _lock___atexit_lock; struct _lock _lock_atexit_mutex; struct _lock _lock___malloc_lock_object; struct _lock _lock___env_lock_object; struct _lock _lock___tz_lock_object; struct _lock _lock_dd_hash_lock; It's better to change it now than in the future. Exact format does not matter much, it would be nice to just keep them similar and maybe have the recursive/normal distinction in the name. I'll investigate whether or not all locks are always needed, as I think that some of them are needed only with specific newlib configurations. Regards, FCh