__getreent in libgloss
Stefan Wallentowitz
stefan.wallentowitz@tum.de
Wed Nov 5 15:19:00 GMT 2014
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.
>>
> Hi,
>
> 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.
>
> Thanks.
>
> Bye,
>
Can this be an option?
https://github.com/wallento/or1k-newlib/commit/53a4f1584ec8702ec1a92eea15fbe937b27a5bd4
Thanks, Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4929 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20141105/34e01cf5/attachment.p7s>
More information about the Newlib
mailing list