This is the mail archive of the
mailing list for the newlib project.
Re: __DYNAMIC_REENT__ part of external API?
- From: "Jonathan S. Shapiro" <shap at eros-os dot org>
- To: Jeff Johnston <jjohnstn at redhat dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Tue, 1 Oct 2013 14:45:58 -0700
- 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> <524B3A9A dot 8010604 at redhat dot com>
On Tue, Oct 1, 2013 at 2:11 PM, Jeff Johnston <firstname.lastname@example.org> wrote:
> 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.
Yes. I had to read it twice, but that could work. Though I'm a little
concerned about the never-ending race with new processor models. I'll
have to look harder at how multilib support actually works. Use of
multilib is still experimental in several of the widely used crosstool
Ultimately, though, I think this needs to end up in a platform header.
>> 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...
Unfortunately, it's more complicated than that.
The RTOS builders don't really want to take a position in their code
about the mechanism for getting the reentrancy pointer. Their view
seems to be that it's better for the client (i.e. the developer using
the RTOS) to modify the thread switch code according to their needs.
The developer is porting the RTOS anyway, so it's much easier to add
an implementation of __getreent() there than it is to patch newlib -
especially when you take into account that ct-ng really isn't set up
to run a user-supplied patch. Keep in mind we are talking about
systems here where the whole thing is linked together into a single
So in those cases where the RTOS is going to supply __getreent(), it
is most easily supplied in the RTOS.
As to why it shouldn't be incorporated into newlib, there are two
reasons. The first is that there are probably a hundred RTOS's out
there, most of which are perfectly happy to use arm-unknown-eabi
tuple. We don't want to add new configure options for each of them. It
would be simpler and cleaner to just have -with-external-getreent. It
might be simpler still to add a new quasi-architecture "armmc" (for
arm multi-core) so that everybody could use armmc-unknown-eabi.
The second is that there is a chicken and egg problem. In many cases,
moving __getreent() into newlib would mean that the OS headers need to
be present in the sysroot before newlib can be build. Keeping
__getreent() in the RTOS avoids this dependency, and simultaneously
permits the _REENT structure to be incorporated into the RTOS's thread
It wasn't my intent to make it optional. Introducing a weak
implementation of __getreent() was more a matter of idiot-proofing, so
that building newlib using "configure --with-external-getreent" would
still get you a working library if somebody wasn't paying attention
and was using the __impure_ptr mechanism in the RTOS. Though this may
be a place where idiot proofing isn't a good idea.
> , 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).
Is it guaranteed that client code will include newlib.h?
> Or you could simply just set the __DYNAMIC_REENT__ flag on permanently in sys/config.h and always supply __getreent() one way or another.
Yes, but this would require a patch, and much of the goal here is to
avoid having things like ct-ng need such a patch.
>> 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.
Can this be done without a patch?
My whole question here is admittedly half baked. What I'm really after
is a way for an outside party to direct the newlib build to proceed on
the assumption that dynamic concurrency will be required, and leave
the implementation of libgloss completely to an outside party. This
makes absolutely no sense when you have a full operating system, but
it may make more sense than trying to patch newlib for an RTOS that is
going to be one-offed by every consuming developer in any case.
I clearly need to give this more thought.