This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Add and use _REENT_GLOBAL_ATEXIT
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: newlib at sourceware dot org
- Date: Fri, 03 May 2013 09:17:50 +0200
- Subject: Re: [PATCH] Add and use _REENT_GLOBAL_ATEXIT
- References: <1367423934-7209-1-git-send-email-sebastian dot huber at embedded-brains dot de> <5182C04E dot 2070501 at redhat dot com>
On 05/02/2013 09:36 PM, Jeff Johnston wrote:
I would like to change this.
I don't like having a macro that takes a ptr argument and ignores it. I also
would prefer consistency with the impure ptr struct declarations. The atexit0
storage is supposed to be statically guaranteed which is currently accomplished
by being part of the static global reent struct.
The problem is that with the current struct _reent you have per-reent atexit
support. I don't know if this is used in code outside of Newlib by some
system. You can for example add your own my_thread_atexit() which registers
atexit() handlers in the thread-local reent which are called during thread
delete via my_thread_delete_call_atexit(). The patch will be simpler if we
accept to break such systems.
My preference is that you declare a static atexit0_data struct inside impure.c
along-side the impure_data declaration (being controlled by your new
_REENT_GLOBAL_ATEXIT macro).
If we place it in impure.c, then we need this space even if nobody calls atexit().
Then, you have two macros:
_GLOBAL_ATEXIT (which is either _GLOBAL_REENT->_atexit or _impure_atexit
(whatever you call it), which is also declared in impure.c based on the
_REENT_GLOBAL_ATEXIT macro.
and
_GLOBAL_ATEXIT0 (which is either &(_GLOBAL_REENT->_atexit0) or the address of
_impure_atexit0_data or whatever you put in impure.c for atexit0).
It becomes relatively straightforward after that to change the existing code.
In _reclaim_reent() we have "&ptr->_atexit0". Changing this to
"&(_GLOBAL_REENT->_atexit0" alters the behaviour.
I probably would not have bothered moving the _atexit pointer out of the struct
myself since it is such a minor gain compared to the atexit0 savings but whatever.
Yes, it saves only some bytes, but this enforces that the atexit() support is
no longer potentially thread-local.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.