This is the mail archive of the
mailing list for the newlib project.
Re: __DYNAMIC_REENT__ part of external API?
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: "Jonathan S. Shapiro" <shap at eros-os dot org>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 01 Oct 2013 17:11:54 -0400
- Subject: Re: __DYNAMIC_REENT__ part of external API?
- Authentication-results: sourceware.org; auth=none
- References: <CAAP=3QNGVwcBq6D+h_+E3QiHwCmL0RVcn-wmd+dsdPhMFLnt-Q at mail dot gmail dot com> <524B222A dot 2070505 at redhat dot com> <CAAP=3QNeSgARSXjFhrrqX7K2uSTA_shvneQO2dVc=VcU3UyBBQ at mail dot gmail dot com>
On 10/01/2013 03:42 PM, Jonathan S. Shapiro wrote:
Thanks for the reply, and for such a succinct identification of the problem.
What brings this on is that I'm bringing up an RTOS on a noMMU multicore
processor. Where use of __getreent() could previously be selected as a
target platform decision, and wasn't commonly used, it now seems to be
more situational. If my build targets a Cortex M3 unicore, the
impure_ptr mechanism works fine. If it instead targets something like an
LPC43xx (Cortex M4+M0), then impure_ptr isn't good enough any more. Note
here that the target tuple between the two is identical, and the
selected OS might also be identical. There isn't an obvious way to
decide whether __DYNAMIC_REENT__ should be defined based on the target
tuple. So it seems to me there is a conceptual model problem here.
I should clarify that it isn't actually the tuple. It is usually
builtins from the tuple's compiler (e.g. platform/model/endian
specifiers). The compiler can have multilib options for a particular
single configuration (e.g. -mmulti or -mlpc43xx could be a multilib
option from the compiler). This could be in turn be used to turn on the
__DYNAMIC_REENT__ flag and the user would be expected to use it when
they used that board.
People who produce cross tool generators are justifiably reluctant to
lug around a long list of patches for various cases. Especially so when
they touch on things that are outside their scope. As a concrete example
here, I was looking at modding FreeRTOS to supply __getreent(), and
either tweaking the config.h or adding __DYNAMIC_REENT__ as a gcc
predefine for my target. y_morin would prefer to see patches pushed
upstream, but you guys would presumably prefer patches that have general
utility (and rightly so).
I wouldn't push __DYNAMIC_REENT__ upstream, but they would certainly be
more inclined to add model specifiers if they don't already have them
which you can use to map to __DYNAMIC_REENT__.
This leads me to wonder whether we shouldn't consider a configure option
--with-dynamic-reent coupled with a default (weak symbol) implementation
of __getreent() that simply returns the current value of impure_ptr (for
A possibility, but you are expecting the end-user to link in the real
__getreent() ahead of time as a special step or you have it in the RTOS
which begs the question, why not just have it in newlib? If you wanted
to make use of it optional, you could have your configure option which
you could use to set __DYNAMIC_REENT__ via newlib.h and this would solve
the header file issue (i.e. library and headers would be consistent).
Or you could simply just set the __DYNAMIC_REENT__ flag on permanently
in sys/config.h and always supply __getreent() one way or another.
This touches on libgloss as well, and I wonder there if we shouldn't
consider --with-external-libgloss or some such thing, so that we can
leave implementation of "system calls" to the selected bare-metal runtime.
You can already handle that with a libgloss linker script which doesn't
link in any library created in libgloss.
But I may be approaching this in entirely the wrong way, so I'd welcome
feedback. Is there a clean way to do this short of patching newlib?