Re: __DYNAMIC_REENT__ part of external API?

[Jeff Johnston <jjohnstn at redhat dot com>]

On 10/01/2013 03:42 PM, Jonathan S. Shapiro wrote:
> Jeff:
>
> 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
> 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, 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?
>
>
> Thanks again.
>
>
>
> Jonathan