Documentation reentrancy
Carl Denzen Van
carl@vandenzen.nl
Thu Mar 2 15:27:00 GMT 2006
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