__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