Re: Documentation reentrancy

[Jeff Johnston <jjohnstn at redhat dot com>]

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