This is the mail archive of the
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 11:06:07 -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> <AF276038-F1D6-4FA4-8D18-B6EF83615C7A at oarcorp dot com> <545A3527 dot 7030403 at tum dot de> <545A3FF3 dot 3080208 at tum dot de>
On 11/5/2014 9:19 AM, Stefan Wallentowitz wrote:
> On 05.11.2014 15:33, Stefan Wallentowitz wrote:
>> On 05.11.2014 15:05, Joel Sherrill wrote:
>>> 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.
>> there are two things:
>> First, I added the reentrancy to support the use of C library
>> routines in exceptions and therefore implement two impure structs,
>> just to not mess up printf buffers during exceptions etc.. Solely for
>> this we don't need dynamic reentrancy, but can just exchange the
>> _impure_ptr. The goal of the whole implementation of exception and
>> interrupt hooks is that people can use the or1k-elf toolchain to
>> build everything including a small scheduler or virtual memory
>> threads, if they need. It is of course debatable that this is necessary.
>> Second, we have multiple cores running the same baremetal code from
>> shared memory. I think this is the point where we need dynamic
>> reentrancy, as we have multiple threads of execution (not meaning "OS
>> threads") that share the code. I am not sure if this already
>> qualifies for another target than *-elf.
OK. Not sure either. For sure there is some added code to know core
number in that configuration that is not needed in uniprocessor
configurations. That's not necessarily a big deal.
But is the same information available for current core number and
maximum cores available in a uniprocessor or1k CPU?
Does the or1k simulator do multicore? Does it have synchronization
instructions? Just curious since SMP RTEMS on or1k is something
I really hadn't thought about. We already support ARM, SPARC,
PowerPC, and x86.
> Can this be an option?
I don't have problems with this patch. As long as the libgloss code includes
all that is needed.
> Thanks, Stefan
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985