Newlib reentrancy

Joel Sherrill joel.sherrill at OARcorp.com
Mon Apr 22 15:10:56 UTC 2013


On 4/22/2013 8:55 AM, Sebastian Huber wrote:
> On 04/22/2013 03:46 PM, Gedare Bloom wrote:
>>>>> The implementation of __getreent() for RTEMS is easy:
>>>>>>>> struct _reent *__getreent(void)
>>>>>>>> {
>>>>>>>> struct _reent *reent = _Thread_Executing->libc_reent;
>>>>>>>>
>>>>>>>> if ( reent == NULL ) {
>>>>>>>> reent = _global_impure_ptr;
>>>>>>>> }
>>>>>>>>
>>>>>>>> return reent;
>>>>>>>> }
>>>>>>
>>>>>> Does this code need locking ?
>>>>
>>>> No, but I haven't tested anything yet.
>>>>
>> Seems right to me. Do we need the check for NULL though, or can we
>> define the invariant that _Thread_Executing->libc_reent is valid
>> pointer to the reent structure?
>>
> I want to avoid the every program needs a reference to the global reentrancy
> structure.  We have the configuration option
> CONFIGURE_DISABLE_NEWLIB_REENTRANCY.  In case this option is defined, then we
> should initialize thread->libc_reent to NULL.  If we initialize it to
> _global_impure_ptr, then we pull in the global reentrancy structure even if we
> don't need it in the application.  If someone needs it, then he gets the
> reference via __getreent().
>
> Now I think that an even better approach is to define __getreent() in
> confdefs.h depending on CONFIGURE_DISABLE_NEWLIB_REENTRANCY, e.g.
>
> struct _reent *__getreent(void)
> {
> #ifdef CONFIGURE_DISABLE_NEWLIB_REENTRANCY
>     return _global_impure_ptr;
> #else
>     return _Thread_Executing->libc_reent;
> #endif
> }
>
I think this is the correct thing to do.

My only concern would be how this impacts any use during system 
initialization.
There is a period of time where _Thread_Executing is not valid. I would 
guess that
the newlib routines requiring reentrancy are unlikely to be used before 
the first
task switch but that is unproven.

Other than that, the reent handling is quite old in RTEMS (ca. 1992-4) and
probably due for a refresh. newilb and RTEMS have evolved a bit since 
then. :)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list