Queries concerning RTOS protection in newllib

[Antony KING <antony dot king at st dot com>]

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.

--
-----------------------------------------------------------------
Antony King                        | Email: antony.king@st.com
STMicroelectronics (R&D) Ltd.      |
Bristol, BS32 4SQ. United Kingdom. | Tel: +44 (0)1454 462646

Attachment: newlib.patch.gz
Description: GNU Zip compressed data

Attachment: lockapi.tar.gz
Description: GNU Zip compressed data