From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14174 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew DeVault Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] RISC-V: add riscv64 architecture support Date: Mon, 03 Jun 2019 16:46:56 -0400 Message-ID: References: <20190526043144.GG23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="118799"; mail-complaints-to="usenet@blaine.gmane.org" To: , Original-X-From: musl-return-14190-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 03 22:47:13 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hXtrN-000Un3-2a for gllmg-musl@m.gmane.org; Mon, 03 Jun 2019 22:47:13 +0200 Original-Received: (qmail 1205 invoked by uid 550); 3 Jun 2019 20:47:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1186 invoked from network); 3 Jun 2019 20:47:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cmpwn.com; s=cmpwn; t=1559595001; bh=8p0QKNwE2FZqkTt3oU5ui4KX9X7u9SLh8FVuQJygsP4=; h=In-Reply-To:To:From:Date:Subject; b=MQM/DAoMOpSGRJjoK7TEZo9hh20uGVrTLZl2fdM8znM4alFqMuYa3pi9ESG7wttJa iHpj6g1N/wcY1rJkbUUZWBMfeb65adpI96BfAOdN4yskVeN4OKt9dZGVaQM5meRX+e 7xKiWij/OpLLLR7kq7Y8bk4J7zHN8O2JSSMHTXDg= In-Reply-To: <20190526043144.GG23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14174 Archived-At: Thanks for your patience, needed to wait until I returned from travel to take another look here. On Sun May 26, 2019 at 12:31 AM Rich Felker wrote: > I don't understand why a_cas is defined here, and it's almost surely > wrong since it has no barriers whatsoever. If a_cas is left undefined, > it would be auto-defined in terms of a_ll and a_sc. But if we want to > follow the ISA docs which place restrictions on the positioning of > ll/sc and what can be done between them, I think we can't define a_ll > and a_sc, but have to define a_cas (with proper barriers) and let > everything else get defined in terms of it... I don't grok the atomics code, to be honest. I'm not sure what the resolution is here. > This is probably gratuitous since there's no big endian ABI defined. > Or if the intent is to have a big endian ABI, that needs to be > reflected in reloc.h. I don't know of any plans for a big-endian ABI. I've removed this for the future v2, and addressed simliar concerns throughout. > Is 2k min correct here? It's ABI so we should aim to get it right to > begin with. The spec doesn't recommend a minimum stack size afaict, so this as reasonable as any other number to me. > > +++ b/arch/riscv64/crt_arch.h > > -%<- >=20 > Is __global_pointer actually used in the hosted ABI? Yes. > > +trycppif __riscv_float_abi_soft "$t" && SUBARCH=3D${SUBARCH}-sf >=20 > Is -sp also supposed to be supported? Yes. > OK, that probably looks like a lot, but very little if anything from > it is blocking. I'm fine with taking patches or writing my own to fix > up things after the initial commit, just as long as we make sure the > initial commit doesn't have known ABI issues resolving whether big > endian is supposed to be supported, and whether single-precision fpu > is supposed to be supported, and what MINSIGSTKSZ should be, are the > main ones I see. I also think the atomics are probably broken enough > that it would be nice to get them fixed. I've pushed a commit which addresses most of your feedback to the staging branch of https://github.com/riscv/riscv-musl. > I'm working on trying to get musl-cross-make in shape so that I can > test a build. At least binutils needs to be updated to a version with > riscv support, and in updating it I need to make sure I get a version > without the x86 regression or add a patch for it.. Hopefully I can > start testing in the next day or two. I can also give you shell access to a RISC-V box if you would prefer to test with real hardware.