Some problems with the libbsd update

[Sebastian Huber]

On 22/08/18 14:06, Joel Sherrill wrote:
>
>
> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 22/08/18 13:44, Joel Sherrill wrote:
>     >
>     >
>     > On Wed, Aug 22, 2018, 4:51 AM Sebastian Huber
>     > <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>     >
>     >     On 22/08/18 09:50, Sebastian Huber wrote:
>     >     > To support everything in RTEMS is a lot of work, so I have
>     to make
>     >     > some trade-offs. The implementation of this API must be as
>     >     efficient
>     >     > as possible since it is used in the critical paths of the
>     network
>     >     > stack. I will try to use a single global epoch and
>     thread-specific
>     >     > records as suggested by Matthew Macy to avoid the need for
>     >     > per-processor data structures and the thread pinning. One key
>     >     issue is
>     >     > that epoch records must not be destroyed:
>     >     >
>     >     > https://www.mankier.com/3/ck_epoch_register
>     >     >
>     >     > The consequence of this is that unlimited thread objects may
>     >     lead to
>     >     > undefined behaviour with this implementation approach. Also
>     >     > thread-local storage cannot be used since it is reinitialized
>     >     once a
>     >     > thread restarted or reused. The epoch record must be
>     included in
>     >     the
>     >     > Thread_Control and must not be touched by
>     _Thread_Initialize().
>     >     This
>     >     > means I have to move the API and its implementation along
>     with the
>     >     > Concurrency Kit to RTEMS.
>     >
>     >     Ok, there is also an
>     >
>     > http://www.concurrencykit.org/doc/ck_epoch_unregister.html
>     >
>     >     and
>     >
>     > http://www.concurrencykit.org/doc/ck_epoch_recycle.html
>     >
>     >     This allows a localized implementation in libbsd.
>     >
>     >     Due to performance reasons this requires the use of thread-local
>     >     storage. Any objections to make thread-local storage a hard
>     >     requirement
>     >     for libbsd support?
>     >
>     >
>     > Not particularly but there should be an effort to identify which
>     > targets do not have TLS support yet. Other than sparc, arm, powerpc
>     > and i386, I don't know the status. Sounds like a series of tickets.
>
>     TLS is also supported on m68k and riscv. Are the other targets
>     maintained at all?
>
>
> Level varies. MIPS is used by Hesham for the CHERI project.

Ok, but is libbsd used here?

>
> 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?
>
> 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.

Is this really an issue for the up to date MIPS processors?

>
> 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.

If the niche architectures don't use libbsd (which I guess is the case), 
then there is no issue at all.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.