[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150428005941.GA2205@newbook>
Date: Mon, 27 Apr 2015 17:59:42 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Cc: yuri.nunami@...wc.com, sumpei.kawasaki@...wc.com
Subject: Re: musl sh2 support
On Mon, Apr 27, 2015 at 05:36:03PM -0400, Rich Felker wrote:
> Recently nsz and I have been looking at the state of the sh port and
> noticed that the gusa soft atomics, which Bobby Bingham (original port
> author) and I assumed would be sufficient for anything pre-sh4a,
> actually don't work on pre-sh3 targets. This is explained on the GCC
> bug-tracker threads here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
>
> but the TL;DR is that gusa works by setting an invalid stack pointer
> as a sentinel to the kernel whereas sh1/sh2 exception-handling
> requires a valid stack pointer. This issue may also affect __unmapself
> which runs momentarily (roughly 1-2 cycles in userspace) without a
> valid stack pointer. For non-SMP configurations I suspect it should
> suffice for __unmapself to just set the stack pointer to point at some
> global data for the kernel to use momentarily during exceptions.
> Alternatively the first thread to call __unmapself could transform
> into a reaper that never exits but unmaps future detached exiting
> threads; this could even be a decent default C-only implementation of
> __unmapself for archs/ABIs that can't handle threads unmapping their
> own stacks.
Heads up: Rob Landley's current work project involves bringing up the
software for a new sh2-compatible chip, the J2 (with BSD-licensed VHDL).
The latest post on his blog refers to SMP support being "nearly" ready
(could be done by now, or might not).
> In addition to the question of what to do with atomics, there's a
> question of whether we need full runtime selection for the atomic
> method at all. I've been told (but I'm not clear whether it's right)
> that sh1/sh2(/sh2a?) have a different kernel syscall ABI, and since
> they're nommu, it wouldn't be possible (or at least not efficiently)
> to run normal dynamic-linked ELF binaries (where syscall ABI wouldn't
> matter as long as you have the right libc.so installed on the system
> you're running on) for sh3+ on sh1/2. So it might make sense to treat
> sh1/sh2 as a separate arch for musl's purposes. But if this arch will
> possibly have SMP implementations (e.g. running on sh4a or new tech)
> then soft-tcb atomics will not suffice and it might need its own
> method of runtime-atomic-selection to get a working atomic cas.
If the J2 gets done, you will have smp and sh2.
HTH,
Isaac Dunham
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
