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

[Thomas Preudhomme <thomas.preudhomme@foss.arm.com>]

Hi Freddie,

Have you had time to work on the last version of the patch?

Best regards,

Thomas

On 16/01/17 15:59, Thomas Preudhomme wrote:
> Please find attached the updated patch.
>
> I've noticed that there is also some target and OS specific locks:
> _arc4random_mutex and many Linux/rtems/tirtos specific locks.
>
> I haven't included those.
>
> Best regards,
>
> Thomas
>
> On 13/01/17 18:16, Thomas Preudhomme wrote:
>>
>>
>> On 13/01/17 18:05, Freddie Chopin wrote:
>>> On Fri, 2017-01-13 at 13:24 +0000, Thomas Preudhomme wrote:
>>>> And here's the patch. Tested with full and partial retargeting as
>>>> well as no
>>>> retargeting.
>>>
>>> I confirm - if I provide just some of the functions/objects, the
>>> linking will fail with "multiple definition" error. Great!
>>>
>>> Any chance for adding all locks used by newlib internally? These 4 are
>>> missing from what I've seen:
>>> newlib/libc/posix/telldir.c:__LOCK_INIT(static, dd_hash_lock);
>>> newlib/libc/time/tzlock.c:__LOCK_INIT(static, __tz_lock_object);
>>> newlib/libc/stdlib/quick_exit.c:__LOCK_INIT(static, atexit_mutex);
>>> newlib/libc/stdlib/envlock.c:__LOCK_INIT_RECURSIVE(static, __env_lock_object);
>>>
>>> I know these are not "popular", but nevertheless required. For example
>>> time-zone locking is pulled by any function dealing with "local" time,
>>> like a very useful mktime(). 4 bytes here or there is not such a big
>>> deal (;
>>
>> Oh yes absolutely. I forgot that I added the lock only based on testing rather
>> than analysis of the code. Thanks for pointing that out.
>>
>> Best regards,
>>
>> Thomas