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: __getreent in libgloss

On November 5, 2014 2:03:31 AM CST, Stefan Wallentowitz <> wrote:
>On 04.11.2014 22:14, Jeff Johnston wrote:
>> That makes sense if you are going to support multiple threads running
>> the cores.
>perfect, thanks!
>There is just one last thing I am not sure about: I (and the most 
>OpenRISC guys) used newlib primarily for baremetal applications 
>(or1k-elf), while the RTEMS port of course uses it differently (say 

The configure magic will pick up the settings, defines, directory selection, etc. RTEMS will have more enabled than a bare metal target and set things so we use our malloc implementation.

>I now handle all the reentrany stuff for baremetal in libgloss [1] (is 
>that correct?) and access it from my newlib __getreent [2]. This will
>course not work with RTEMS (and therefore maybe not accepted). What is 
>the legitimate way to handle this? Some preprocessor magic? Or am I 
>getting something entirely wrong?

If your bare metal target doesn't have threads, this reentrancy isn't an issue. If it does, then I would tend to think that the target should not be or1k-elf but something indicating the thread package. It would also have lock support. 

I think all the bare *-elf targets are single threaded focused although some RTOSes use them anyway.

>My solution would be: Distinguish between or1k-*-elf and or1k-*-* in 
> and either set __DYNAMIC_REENT__ and __getreent there or
>set some defines that are then used in [2].
Elf should be simple and single threaded IMO. Another target name should be used for a threaded runtime.


>Thanks again for for quick help.
>Best regards,

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