Queries concerning RTOS protection in newllib

Jeff Johnston jjohnstn@redhat.com
Thu Sep 16 21:34:00 GMT 2004


Corinna Vinschen wrote:
> On Jun 18 11:24, Corinna Vinschen wrote:
> 
>>On Jun 17 14:07, Jeff Johnston wrote:
>>
>>>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.
>>
>>Thanks for backing this out for now.  Unfortunately I can't tell for sure
>>so far what the exact problem is.  I tried several changes already but
>>to no avail.  Unfortunately I don't have experience with the impure_ptr
>>stuff so I'm a bit shooting in the dark here.  I'll send a heads up to
>>cygwin-developers list.
> 
> 
> I have investigated further, triggered by the recent reent problem
> and I found why the change to use _global_impure_ptr broke Cygwin.
> 
> The reason is that Cygwin never used the impure_data structure and the
> original _impure_ptr value provided by newlib, but instead it maintains
> its own global struct reent called `reent_data'.  Therefore, all
> usages of GLOBAL_REENT inside of newlib pointed to the wrong data structure.
> 
> I have a local patch to Cygwin, which allows to revert the definition
> of _GLOBAL_REENT to _global_impure_ptr.  The patch removes reent_data
> entirely and let Cygwin use the data structures provided by newlib's
> impure.c.
> 
> Unfortunately, there's a problem left.  reent_data has been exported by
> the Cygwin DLL and unfortunately there are apps and libraries out there
> which make use of that datastructure, namely libitcl32.a.  That's a pain,
> but since backward compatibility is an important factor, we can't just
> get rid of the reent_data export.
> 
> So I'd like to suggest the following change to newlib.  It aliasses reent_data
> to be the same as impure_data and so allows to further export that symbol,
> and it reverts _GLOBAL_REENT to _global_impure_ptr.
>

Thanks for looking into this.  I am happy to see that we have removed this 
problem.  Patch checked in.

-- Jeff J.

> 
> Corinna
> 
> 
> 	* libc/reent/impure.c (reent_data): Define as alias to impure_data
> 	when building for Cygwin.
> 	* libc/include/sys/reent.h (_GLOBAL_REENT): Revert definition to
> 	_global_impure_ptr.
> 
> Index: libc/reent/impure.c
> ===================================================================
> RCS file: /cvs/src/src/newlib/libc/reent/impure.c,v
> retrieving revision 1.2
> diff -p -u -r1.2 impure.c
> --- libc/reent/impure.c 11 Jun 2004 20:37:10 -0000      1.2
> +++ libc/reent/impure.c 15 Sep 2004 10:41:34 -0000
> @@ -10,5 +10,8 @@
>  #endif
>  
>  static struct _reent __ATTRIBUTE_IMPURE_DATA__ impure_data = _REENT_INIT (impure_data);
> +#ifdef __CYGWIN__
> +extern struct _reent reent_data __attribute__ ((alias("impure_data")));
> +#endif
>  struct _reent *__ATTRIBUTE_IMPURE_PTR__ _impure_ptr = &impure_data;
>  struct _reent *_CONST __ATTRIBUTE_IMPURE_PTR__ _global_impure_ptr = &impure_data;
> Index: libc/include/sys/reent.h
> ===================================================================
> RCS file: /cvs/src/src/newlib/libc/include/sys/reent.h,v
> retrieving revision 1.30
> diff -p -u -r1.30 reent.h
> --- libc/include/sys/reent.h    9 Sep 2004 19:46:54 -0000       1.30
> +++ libc/include/sys/reent.h    15 Sep 2004 10:41:34 -0000
> @@ -816,7 +816,7 @@ void _reclaim_reent _PARAMS ((struct _re
>  
>  #endif /* !_REENT_ONLY */
>  
> -#define _GLOBAL_REENT _impure_ptr
> +#define _GLOBAL_REENT _global_impure_ptr
>  
>  #ifdef __cplusplus
>  }
> 



More information about the Newlib mailing list