From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7532 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl sh2 support Date: Mon, 27 Apr 2015 17:59:42 -0700 Message-ID: <20150428005941.GA2205@newbook> References: <20150427213603.GA23866@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1430182800 29018 80.91.229.3 (28 Apr 2015 01:00:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 01:00:00 +0000 (UTC) Cc: yuri.nunami@swhwc.com, sumpei.kawasaki@swhwc.com To: musl@lists.openwall.com Original-X-From: musl-return-7545-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 28 02:59:54 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YmtsO-0008RI-TW for gllmg-musl@m.gmane.org; Tue, 28 Apr 2015 02:59:53 +0200 Original-Received: (qmail 32469 invoked by uid 550); 28 Apr 2015 00:59:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32449 invoked from network); 28 Apr 2015 00:59:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pyvigw2uh1sTbCPlMIl0YQ45vkHPCtfAssMONL4Ld/A=; b=nIrgINp38E1NIVQLosH408BTskW3VBH/0Rt7aVzirbXUJG6umSkTEAXkoQS7koj+cH L+HQAmA0wsnsulXHXTKuTfxZyXSHXXIFLfPN6rsCp8lkLzerkcV8g6yAizu3ykzxmH6Y iEbadvGa/ZjY6lh2WVafzl50x6relXl7B/Jng2F8RLWPeRJylU0fi+858ekrLYFIwefa S40cALyR6G37FVZstoRrC5tZs/JxBOeHa0b6huVqPiE05TbLRjRVsQa3lWGu3oPOMV/I 5Z5XOybth7GZ96MBzpWEtqOLW7kBc3NTlKQ+nwcHRQt8SSPdWz6e/dnmxKWfjMftbYtk AJ7g== X-Received: by 10.68.219.101 with SMTP id pn5mr27278046pbc.77.1430182778729; Mon, 27 Apr 2015 17:59:38 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20150427213603.GA23866@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7532 Archived-At: 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