AW: [PATCH, newlib] Allow locking routine to be retargeted

onkel.jack@t-online.de onkel.jack@t-online.de
Fri Nov 11 11:20:00 GMT 2016


To build multithread for running singlethread seems not to make sense to me.
On the other hand, bare metal could implement some threading model without undergoing the pain to put another OS implementation into newlib.
In fact I'm doing so at the moment by patching lock.h (not a good solution through).

I figured out in practice, building newlib for multithread with no locks implemented just lead to a binary that will crash if malloc will be used concurrent. I would consider this as a formal bug first hand.  

So any improvement would be highly welcome.
I will try to build a proposal solution next days. 
Only problem I see there is the typedefs in lock.h.

-----Original-Nachricht-----
Betreff: Re: AW: [PATCH, newlib] Allow locking routine to be retargeted
Datum: 2016-11-11T12:02:15+0100
Von: "Thomas Preudhomme" <thomas.preudhomme@foss.arm.com>
An: "newlib@sourceware.org" <newlib@sourceware.org>



On 11/11/16 09:37, onkel.jack@t-online.de wrote:
> Hello,
>
> to unconditionally provide weak dummy implementation I dont think its a good idea since it has some implications:
> If the newlib is compiled for single thread, no locks are required at all, so the dummy implementation/macro is doing the job to
> satisfy the linker.
> But for multithread its dangerous to provide a dummy since you would not see first hand there are no locks but dummys.

I don't see how is that different from what is happening now. Right now for 
bare-metal targets the locking macro are always void ones.

>
> So my suggestion would be:
> - For single thread leave the implementation as is.
> - For multithread, dont provide any lock function, so linking newlib without to provide locking functions from os/kernel
> would result in a linkage error, therefore forces the user not to forget to provide them.
>
> So I think, just put something like #ifndef MULTI_THREAD around the existing macros would do it.

That would defeat the purpose IMO. The point is to provide a single newlib build 
for both single threaded and multithreaded applications: newlib would be built 
for multithread environment and would work fine for single thread without need 
to define any function and multithread applications (or more likely the RTOS) 
can define locking functions to make it work.

Best regards,

Thomas




More information about the Newlib mailing list