Some problems with the libbsd update

[Joel Sherrill]

On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber <
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>> 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.

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.

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.

>
> --
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180822/37ff7625/attachment-0002.html>