Some problems with the libbsd update
sebastian.huber at embedded-brains.de
Wed Aug 22 12:25:59 UTC 2018
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
> > > stack. I will try to use a single global epoch and
> > > 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
> > 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.
More information about the devel