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