Queries concerning RTOS protection in newllib

[Jeff Johnston]

Corinna Vinschen wrote:
> On Jun 17 14:32, Antony KING wrote:
> 
>>Hi Corinna,
>>
>>Which part of the patch was causing the problem ? Was it just the 
>>introduction of _global_impure_ptr ? I recently discovered a problem 
> 
> 
> As far as I can see, yes.  Since impure_ptr is manipulated a lot in Cygwin,
> changing _GLOBAL_REENT from _impure_ptr to _global_impure_ptr is a big
> problem.  If I keep all other patches but revert _GLOBAL_REENT to be defined
> as _impure_ptr, everything seems to work fine. 
> 
> 
>>which was exposed by this patch when the _cleanup_r function was changed 
>>from walking the FILE object list with fflush() to fclose(). I wonder if 
>>this is the cause of the unexpected truncation.
> 
> 
> I didn't see any negative result of this change so far.
> 
> 
>>in addition to the above change (in _cleanup_r) perhaps the definition 
>>of _GLOBAL_REENT can also be conditional on whether newlib is being 
>>targeted for Cygwin, e.g. (in libc/include/sys/reent.h):
>>
>>#ifdef __CYGWIN__
>>#define _GLOBAL_REENT _impure_ptr
>>#else
>>#define _GLOBAL_REENT _global_impure_ptr
>>#endif
>>
>>which may restore the behaviour you need. Alternatively as well as 
>>manipulating _impure_ptr Cygwin can manipulate _global_impure_ptr as well.
> 
> 
> As I said, reverting _GLOBAL_REENT to _impure_ptr restores the correct
> behaviour again.  I still don't quite understand the invention of
> _global_impure_ptr.  _GLOBAL_REENT is used a lot in newlib and due to
> it's redefinition to another global variable, all this functionality
> is potentially accessing the wrong datastructure.  If you actually
> need a never changing _global_impure_ptr, then that's ok, but it shouldn't
> be used by default from all these functions and therefore not be defined
> as _GLOBAL_REENT, should it?
> 

Actually, it shouldn't change based on its reason for being.  It is meant to be 
global across threads.  It stores the full file chain for "all" threads 
(excepting thread std streams for the moment) and it also has the full atexit list.

While I have no problem in backing off the change for the moment to keep Cygwin 
up and running, I would like to see further investigation as to why Cygwin 
depends on _GLOBAL_REENT changing in tandem with _REENT (_impure_ptr).  It might 
indicate a missing usage of _GLOBAL_REENT in newlib or a logic flaw in Cygwin.

-- Jeff J.