[PATCH 2/2, newlib] Allow locking routine to be retargeted

[Thomas Preudhomme]

Hi,

At the moment when targeting bare-metal targets or systems without definition 
for the locking primitives newlib, uses dummy empty macros. This has the 
advantage of reduced size and faster implementation but does not allow the 
application to retarget the locking routines. Retargeting is useful for a single 
toolchain to support multiple systems since then it's only at link time that you 
know which system you are targeting.

This patch adds a new configure option --enable-newlib-retargetable-locking to 
use dummy empty functions instead of dummy empty macros. The default is to keep 
the current behavior to not have any size or speed impact on targets not 
interested in this feature. To allow for any size of lock, the _LOCK_T type is 
changed into pointer to struct _lock and the _init function are tasked with 
allocating the locks. The platform being targeted must provide the static locks. 
A dummy implementation of the locking routines and static lock is provided for 
single-threaded applications to link successfully out of the box.

To ensure that the behavior is consistent (either no locking whatsoever or 
working locking), the dummy implementation is strongly defined such that a 
partial retargeting will cause a doubly defined link error. Indeed, the linker 
will only pull in the file providing the dummy implementation if it cannot find 
an implementation for one of the routine or lock.

Testing: I've built a simple test program that calls malloc and free with all 
the locking function defined in the same file. Running into a debugger with 
breakpoints on the function shows that they are indeed called. Newlib testsuite 
(the 30 tests that run wich check-target-newlib from GCC) also comes back clean.

Is this ok for master branch?

Best regards,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newlib_retargetable_locking_routine.patch
Type: text/x-patch
Size: 19355 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170124/bdf2aaa2/attachment.bin>