__DYNAMIC_REENT__ part of external API?

[Jeff Johnston]

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
>