This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Documentation reentrancy


Thank you. I will implement choice 4.
And meanwhile I ran into the next errors when I compile the simple stubs from the docs:
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





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]