From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54260 invoked by alias); 11 Nov 2016 14:10:13 -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 54249 invoked by uid 89); 11 Nov 2016 14:10:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=the, be, H*i:sk:cfffa4d, H*f:sk:cfffa4d X-HELO: smtpo74.poczta.onet.pl Received: from smtpo74.poczta.onet.pl (HELO smtpo74.poczta.onet.pl) (141.105.16.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Nov 2016 14:10:02 +0000 Received: from INFERNUS (213-238-95-10.adsl.inetia.pl [213.238.95.10]) (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 3tFhcx5XqZzjYj9fG for ; Fri, 11 Nov 2016 15:09:53 +0100 (CET) Message-ID: <1478873392.1232.5.camel@op.pl> Subject: Re: [PATCH, newlib] Allow locking routine to be retargeted From: Freddie Chopin To: newlib@sourceware.org Date: Fri, 11 Nov 2016 14:10:00 -0000 In-Reply-To: References: <1478792031.1254.1.camel@op.pl> <60acaa10-fb22-8655-fd67-0536fe359871@foss.arm.com> <1478809956.1322.1.camel@gmail.com> <707976084.18201.1478865372907.JavaMail.zimbra@embedded-brains.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016/txt/msg01095.txt.bz2 On Fri, 2016-11-11 at 13:40 +0000, Thomas Preudhomme wrote: > Right, I didn't think of extra features. The one thing I could think > of would be  > to remove usage of the static initializers and only use the function > initializer  > which could do a malloc if needed. The issue you described with > malloc can be  > avoided by redefining malloc_lock so as not to call the generic lock > function. > > Now whether this is worth the trouble is another issue because that > would  > require more work. Thanks a lot for the feedback, I'm glad you > pointed out the  > pitfalls in that approach. It is time to go back to the drawing > board. See my earlier message to onkel.jack - I've given some alternative options there at the end, the one you mentioned is also there. It has a major problem, that it's not easily possible to actually execute these initialization functions for most of the global locks... https://sourceware.org/ml/newlib/2016/msg01093.html Regards, FCh