Documentation reentrancy
Jeff Johnston
jjohnstn@redhat.com
Thu Mar 2 15:33:00 GMT 2006
The __DYNAMIC_REENT__ flag is currently set manually in
libc/include/sys/config.h. It is looked at by libc/include/sys/reent.h
which then defines _REENT to be a call to __getreent() instead of the
default which is to define _REENT to be _impure_ptr.
The libgloss reference was for you to look at a working libgloss
implementation to figure out how to write a libgloss library. It has
nothing to do with your reentrancy problem.
-- Jeff J.
It is not documented
Carl Denzen Van wrote:
> Hello Jeff,
>
> I cannot figure out how to "Set the __DYNAMIC_REENT__ flag for the
> platform" (and I think you named it also "__DYNAMIC_REENTRANCY__").
> Where can I find documentation?
> Do I have to call the _getreent() myself in the stubs? Or is it already
> implemented at another level in newlib?
> In the working libgloss/mn10300 I did not find anything about
> reentrancy in the way you explained.
>
> Carl.
>
>
>
> Op 16-feb-2006, om 0:21 heeft Jeff Johnston het volgende geschreven:
>
>> Carl Denzen Van wrote:
>>
>>> Thank you. I will implement choice 4.
>>
>>
>>
>>> And meanwhile I ran into the next errors when I compile the simple
>>> stubs from the docs:
>>
>>
>> I wouldn't suggest implementing those strictly from the docs as they
>> have the wrong names to start with and there is already an
>> implemented library of these stubs available for you in libgloss/
>> libnosys (sans _exit and crt0 which you should provide in
>> assembler). You simply add -lnosys to the end of your link or embed
>> the reference in your ld script or spec file.
>>
>> I usually suggest looking at working implementations (e.g. libgloss/
>> mn10300).
>>
>> -- Jeff J.
>>
>>
>>
>>> stubsc.c: In function `sbrk':
>>> stubsc.c:108: `stack_ptr' undeclared (first use in this function)
>>> stubsc.c:108: (Each undeclared identifier is reported only once
>>> stubsc.c:108: for each function it appears in.)
>>> stubsc.c:110: warning: implicit declaration of function `_write'
>>> stubsc.c: At top level:
>>> stubsc.c:122: conflicting types for `stat'
>>> /usr/local/m6811-elf/include/sys/stat.h:124: previous declaration
>>> of `stat'
>>> stubsc.c:131: warning: `struct tms' declared inside parameter list
>>> stubsc.c:131: warning: its scope is only this definition or
>>> declaration, which is probably not what you want.
>>> stubsc.c: In function `write':
>>> stubsc.c:162: warning: implicit declaration of function `writechar'
>>> Another improvement to the documentation would be to mention the
>>> files to be included. I include (after "grep"ping an evening for
>>> the missing entries):
>>> #include <sys/types.h>
>>> #include <sys/stat.h>
>>> #include <stdlib.h>
>>> #include <errno.h>
>>> #undef errno
>>> extern int errno;
>>> Carl van Denzen. (trying to make it running on Motorola 6811)
>>> Op 15-feb-2006, om 23:29 heeft Jeff Johnston het volgende geschreven:
>>>
>>>> Carl van Denzen wrote:
>>>>
>>>>> I am working on a very simple application, but do not know what
>>>>> is the best solution. The documentation is not clear enough (for
>>>>> me).
>>>>> From the mailing list, the preferred way is NOT to use the
>>>>> _xxxx_r functions. Mention this preference in the docs.
>>>>> The documentation phrase "Each function which uses the global
>>>>> reentrancy structure uses the global variable _impure_ptr, which
>>>>> points to a reentrancy structure." is confusing. Is there really
>>>>> a GLOBAL reentrancy structure?
>>>>
>>>>
>>>>
>>>> Yes. I guess it would be clearer to call it the default
>>>> reentrancy structure that is of global-scope. It is used by
>>>> functions that have
>>>> both a regular and _r form. The regular form of the function
>>>> calls the _r version, passing the default reentrancy structure
>>>> "or" if __DYNAMIC_REENTRANCY__ is set to true, it calls the
>>>> function __getreent() to get a reentrancy structure which is then
>>>> passed to the _r version.
>>>>
>>>> This leads to the following choices:
>>>>
>>>> 1. With no threading, just let functions use the default reentrancy
>>>> struct (i.e. do nothing and don't worry about calling _r routines).
>>>> 2. Call _r routines only and manually pass an appropriate reentrancy
>>>> struct (one allocated per thread).
>>>> 3. Update the _impure_ptr manually at thread switches and call the
>>>> regular forms of functions (i.e. don't worry about calling _r
>>>> suffixed functions).
>>>> 4. Set the __DYNAMIC_REENT__ flag for the platform and
>>>> provide a __getreent() function that returns a unique reentrancy
>>>> struct for the current running thread. Call regular forms
>>>> of functions.
>>>>
>>>>> An improvement to the documentation would be an addition to
>>>>> choice 2 (which I think is the preferred choice): "The global
>>>>> _impure_ptr should be set to point to the thread-dependent _reent
>>>>> at every thread switch by the OS".
>>>>>
>>>>
>>>> Actually, I would say choice 4 is the preferred choice for threaded
>>>> newlib.
>>>>
>>>>> Cheers,
>>>>> Carl
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
More information about the Newlib
mailing list