[PATCH, newlib] Allow locking routine to be retargeted

[Thomas Preudhomme]

On 24/11/16 07:44, Sebastian Huber wrote:
> Hello Thomas,
>
> On 23/11/16 15:38, Thomas Preudhomme wrote:
>> Hi Sebastian,
>>
>> I was thinking on how to solve this issue and found two possible solutions:
>>
>> 1) select size of lock at configure time
>>
>> Instead of being an enable/disable option the configure option could take an
>> integer value N that determine the size of lock, default being the size of a
>> pointer. The lock would then be defined as an array of N integers.
>>
>> Pro: LOCK_INIT works, simpler & smaller change
>> Cons: lock needs to be as big as the biggest lock among all the platforms you
>> want to target wasting a bit of space.
>>
>> 2) Remove static initialization of locks
>>
>> Remove all LOCK_INIT and add code as required to call lock_initialize at start
>> up time.
>>
>> Pro: you only pay the size for the lock you need (ie nothing except empty
>> functions in the single threaded case)
>> Cons: much bigger work, start up cannot support multithread
>
> 3)
>
> struct _lock;
>
> typedef struct _lock *_LOCK_T;
>
> #define __LOCK_INIT(class, lock) extern struct _lock _lock_ ## lock; class
> _LOCK_T lock = &_lock_ ## lock;
>
> The OS must then provide struct _lock and storage for all statically initialized
> locks.

Oh nice, clever. I've check whether there is name collision in the source where 
this would lead them to use the same lock and found:

newlib/libc/sys/linux/iconv/gconv_db.c: __LOCK_INIT(static, lock);
newlib/libc/sys/linux/iconv/gconv_trans.c: __LOCK_INIT(static, lock);

The one thing I worry is the risk of new lock being added with the same name. 
Fortunately this could be detected at link time by looking for relocation to 
"_lock_.*" in newlib library and check that there is no duplicate.

Best regards,

Thomas