<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22/08/18 13:44, Joel Sherrill wrote:<br>
><br>
><br>
> On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
><br>
>     On 22/08/18 09:50, Sebastian Huber wrote:<br>
>     > To support everything in RTEMS is a lot of work, so I have to make<br>
>     > some trade-offs. The implementation of this API must be as<br>
>     efficient<br>
>     > as possible since it is used in the critical paths of the network<br>
>     > stack. I will try to use a single global epoch and thread-specific<br>
>     > records as suggested by Matthew Macy to avoid the need for<br>
>     > per-processor data structures and the thread pinning. One key<br>
>     issue is<br>
>     > that epoch records must not be destroyed:<br>
>     ><br>
>     > <a href="https://www.mankier.com/3/ck_epoch_register" rel="noreferrer noreferrer" target="_blank">https://www.mankier.com/3/ck_epoch_register</a><br>
>     ><br>
>     > The consequence of this is that unlimited thread objects may<br>
>     lead to<br>
>     > undefined behaviour with this implementation approach. Also<br>
>     > thread-local storage cannot be used since it is reinitialized<br>
>     once a<br>
>     > thread restarted or reused. The epoch record must be included in<br>
>     the<br>
>     > Thread_Control and must not be touched by _Thread_Initialize().<br>
>     This<br>
>     > means I have to move the API and its implementation along with the<br>
>     > Concurrency Kit to RTEMS.<br>
><br>
>     Ok, there is also an<br>
><br>
>     <a href="http://www.concurrencykit.org/doc/ck_epoch_unregister.html" rel="noreferrer noreferrer" target="_blank">http://www.concurrencykit.org/doc/ck_epoch_unregister.html</a><br>
><br>
>     and<br>
><br>
>     <a href="http://www.concurrencykit.org/doc/ck_epoch_recycle.html" rel="noreferrer noreferrer" target="_blank">http://www.concurrencykit.org/doc/ck_epoch_recycle.html</a><br>
><br>
>     This allows a localized implementation in libbsd.<br>
><br>
>     Due to performance reasons this requires the use of thread-local<br>
>     storage. Any objections to make thread-local storage a hard<br>
>     requirement<br>
>     for libbsd support?<br>
><br>
><br>
> Not particularly but there should be an effort to identify which <br>
> targets do not have TLS support yet. Other than sparc, arm, powerpc <br>
> and i386, I don't know the status. Sounds like a series of tickets.<br>
<br>
TLS is also supported on m68k and riscv. Are the other targets <br>
maintained at all?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Level varies. MIPS is used by Hesham for the CHERI project.</div><div dir="auto"><br></div><div dir="auto">I tried to make a sweep to identify the method used by each architecture for TLS support and wasn't very successful. If it turns out they call a C method for get tls, then it is easy. Do you know how to easily cipher that out if the GCC source?</div><div dir="auto"><br></div><div dir="auto">And unless there is a GCC internal flag to throw to change it, the MIPS uses a specific undefined instruction and you would have to implement get TLS in the exception handler. </div><div dir="auto"><br></div><div dir="auto">It really is necessary to know how the other architectures implement it. Some may turn out to be easy. Others like Epiphany and new may never matter.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : +49 89 189 47 41-16<br>
Fax     : +49 89 189 47 41-09<br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div></div></div>