This is the mail archive of the 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 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?

Thanks again.


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