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