Queries concerning RTOS protection in newllib

[Jeff Johnston]

Thanks Antony.  Patch checked in.  A patch was also required to get x86-linux 
building with these changes so I added that as well.  In the future, it would be 
helpful to me if you could add a ChangeLog entry for any changes you make.

-- Jeff J.

Antony KING wrote:
> Hi,
> 
> I am currently in the process of adapting newlib co-operate with an ST
> developed embedded RTOS. FYI this RTOS is pretty much standard in terms
> of capability (e.g. tasks, mutexes, semaphores, interrupt handlers) and
> an application is RTOS enabled by simply linking in a static library and
> using the API. The target is an SH4 based device.
> 
> My goal in adapting newlib for this RTOS is that the same static C
> library can be used in applications which either use the RTOS library or
> do not. Also, I would like to reduce the impact of changes I need to
> make to newlib. As a result I have provided my own implementation of
> sys/lock.h which implements the locking API as stub functions (instead
> of empty macros) which will be overridden when a application is linked
> against the RTOS static library. Also, I am aiming to get the RTOS to
> switch the task re-entrancy structures by modifying _impure_ptr at each
> context switch (instead of using a __getreent() function).
> 
> Enough of the background, now my queries and solutions:
> 
> 1) There is a macro _GLOBAL_REENT which is used to obtain the global
> re-entrancy structure used for managing the atexit handlers and FILE
> objects. This is currently defined to be _impure_ptr which of course is
> incompatible with changing _impure_ptr on each context switch.
> 
> My solution is to add a new variable, _global_impure_ptr, to impure.c
> which initially has the same value as _impure_ptr and is the value
> returned by _GLOBAL_REENT. The value of this variable should never change.
> 
> Files affected: impure.c, sys/reent.h
> 
> 2) Given that I am providing an alternative implementation of sys/lock.h
> the current type definition for the FILE lock (_flock_t) is incorrect,
> especially in light of the explicit casting (and de-referencing) to
> _LOCK_RECURSIVE_T in a number of files when invoking the locking API.
> The reason is that the definition of _LOCK_RECURSIVE_T may not be the
> same size as the current type (int) for _flock_t.
> 
> I think _flock_t should be redefined to be of type _LOCK_RECURSIVE_T
> (instead of int) and all the explicit casting be removed.
> 
> Files affected: sys/_types.h, fclose.h findfp.c fopen.c, freopen.c,
> fopen64.c, vfprintf.c
> 
> 3) It would be useful if the stub implementations of the specialised
> locking APIs __malloc_lock/unlock and __env_lock/unlock use the locking
> API defined in sys/lock.h. This would then mean that these functions
> would not need overriding by an RTOS if sys/lock.h is RTOS ready.
> (Actually I do have to override the malloc lock API since I need to
> pre-allocate the malloc lock object under the control of the RTOS since
> the type is opaque and cannot be fully initialised statically).
> 
> Files affected: envlock.c, mlock.c.
> 
> Similarly it would also be useful for the stdio file locking API
> _flockfile/_funlockfile to be modified in the same way.
> 
> Files affected: sys/stdio.h.
> 
> I have attached a patch file incorporating all the changes I have made
> to the newlib library (against a CVS snapshot dated 03 June 2004). The
> implementation of the locking API (lock.h and lock.c) is also attached
> for reference.
> 
> Please note that the patch includes some additional changes in the file
> sys/_reent.h where the re-entrancy structure initialisation macros have
> been slightly re-worked to make them more readable (for me :-), complete
> (I hope) and efficient (greater use of memset). Also the implementation
> of _cleanup_r has been altered so that fclose is called instead of
> fflush when walking the FILE object list.
> 
> Comments please (and sorry for the overlong email).
> 
> Cheers,
> 
> Antony.
>