This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __DYNAMIC_REENT__ part of external API?


On 10/01/2013 05:45 PM, Jonathan S. Shapiro wrote:
On Tue, Oct 1, 2013 at 2:11 PM, Jeff Johnston <jjohnstn@redhat.com> 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
construction systems.

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
compatibility).


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
image.

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
structure.


You don't need the RTOS to implement full __getreent functionality. For example, you could have __getreent() supply a syscall that provides a unique thread id for the current thread. You could then implement a hash table in C which contains addresses of REENT structures. The RTOS only needs to support giving you a unique thread id and because it is a syscall, no OS header should be necessary (just the syscall number is needed and you could mandate its value).

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?


Yes. All the C headers (e.g. stdio.h) include _ansi.h which includes newlib.h ahead of sys/config.h. The newlib.h file has various flags that are dynamically set via configuration.

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?


You can always create a linker script that isn't part of libgloss. Adding one for everyone to use is simply good manners :) and isn't any more of a patch than adding a --with-external-libgloss configuration option.


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.


Ok.



Jonathan



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]