Re: [PATCH 0/3] Reentrancy

Hi Sebastian,

given you're the one pushing the thread_local change in the first
place, would you mind to review this, too?  Looks good to me, but
I'd like to have your input on this.

If you think the patches are ok, feel free to push them.


Thanks,
Corinna


On Aug 30 12:16, Pekka Seppänen wrote:
> Hi,
> 
> The following patch series provides small (one line) fixes for newlib/libc
> reentrancy when using --enable-newlib-reent-thread-local and uses the
> existing
> infrastructure to do that:
> 
>   - There were a few locations on which _errno member was directly accessed.
> As struct _reent is not available if _REENT_THREAD_LOCAL is defined, any
> accesses to errno shall be done using the corresponding _REENT_ERRNO()
> macro.
> Should be self-explanatory.
> 
>   - __getreent() did not check that struct _reent and _impure_ptr were
> available.  Both <sys/reent.h> and impure.c, that declare and define
> _impure_ptr, use similar #ifdef/ifndef gate.  If thread-local storage is
> used
> the allocated objects are not related to each other.  Therefore __getreent()
> does not exist even at a concept level, hence should not be provided at all.
> 
>   - As _Thread_local might not be available (as in that particular keyword),
> <sys/reent.h> shall include <sys/cdefs.h> that will provide a correct
> mapping,
> should the compiler actually support thread-local storage.  A prime example
> is
> libstdc++ configure, which uses #include <math.h> in some of the generated
> checks.  Essentially any C++ target is affected and possibly C targets in
> near future as C23 uses thread_local, not _Thread_local.
> 
> It should be noted that libgloss is affected by similar reentrancy issues,
> but
> I decided not to touch those.
> 
> -- Pekka