|
Message-ID: <20150428010839.GK17573@brightrain.aerifal.cx> Date: Mon, 27 Apr 2015 21:08:39 -0400 From: Rich Felker <dalias@...c.org> To: Isaac Dunham <ibid.ag@...il.com> Cc: musl@...ts.openwall.com, yuri.nunami@...wc.com, shumpei.kawasaki@...wc.com Subject: Re: musl sh2 support On Mon, Apr 27, 2015 at 05:59:42PM -0700, Isaac Dunham wrote: > 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). Yes. I actually CC'd a couple of the people working on this. I don't know all the details of their project though. > > 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. In that case we need to figure out how to make atomics work in a way that's SMP-compatible. I'm a bit concerned from some things Rob said that it might not be possible without a machine-wide lock with the current design... Rich
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.