This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: __getreent in libgloss
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Stefan Wallentowitz <stefan dot wallentowitz at tum dot de>,Jeff Johnston <jjohnstn at redhat dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 5 Nov 2014 08:05:47 -0600
- Subject: Re: __getreent in libgloss
- Authentication-results: sourceware.org; auth=none
- References: <5457880D dot 9040602 at tum dot de> <1165383758 dot 4082281 dot 1415051438222 dot JavaMail dot zimbra at redhat dot com> <5458B035 dot 2090100 at tum dot de> <1514665783 dot 4636414 dot 1415135693176 dot JavaMail dot zimbra at redhat dot com> <5459D9D3 dot 9050908 at tum dot de>
On November 5, 2014 2:03:31 AM CST, Stefan Wallentowitz <stefan.wallentowitz@tum.de> wrote:
>On 04.11.2014 22:14, Jeff Johnston wrote:
>> That makes sense if you are going to support multiple threads running
>on
>> the cores.
>>
>Hi,
>
>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
>or1k-rtems).
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
>of
>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
>configure.host 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.
--joel
>Thanks again for for quick help.
>
>Best regards,
>Stefan
>
>[1]:
>https://github.com/wallento/or1k-newlib/blob/master/libgloss/or1k/impure.c
>[2]:
>https://github.com/wallento/or1k-newlib/blob/master/newlib/libc/machine/or1k/getreent.c