Created attachment 387606 [details, diff] Add RISC-V arch strings This patch provides support for the RISC-V ISA: http://riscv.org/ I'm trying to get a crossdev to build a RISC-V toolchain and this is the one patch that I think I need to get upstream to make this work. Note that this has been accepted into GNU config, so the names are pretty much fixed: https://lists.gnu.org/archive/html/config-patches/2014-09/msg00003.html
(In reply to Palmer Dabbelt from comment #0) > Created attachment 387606 [details, diff] [details, diff] > Add RISC-V arch strings > > This patch provides support for the RISC-V ISA: http://riscv.org/ > > I'm trying to get a crossdev to build a RISC-V toolchain and this is the one > patch that I think I need to get upstream to make this work. Note that this > has been accepted into GNU config, so the names are pretty much fixed: > https://lists.gnu.org/archive/html/config-patches/2014-09/msg00003.html Are we really there yet?
(In reply to Anthony Basile from comment #1) > (In reply to Palmer Dabbelt from comment #0) > > Created attachment 387606 [details, diff] [details, diff] [details, diff] > > Add RISC-V arch strings > > > > This patch provides support for the RISC-V ISA: http://riscv.org/ > > > > I'm trying to get a crossdev to build a RISC-V toolchain and this is the one > > patch that I think I need to get upstream to make this work. Note that this > > has been accepted into GNU config, so the names are pretty much fixed: > > https://lists.gnu.org/archive/html/config-patches/2014-09/msg00003.html > > Are we really there yet? Sorry, I'm a bit confused by your question: who are "we" in that sentance? I think adding RISC-V support is reasonable: There are a number of hardware implementations and we (the RISC-V project) are working on upstreaming our ports of Linux, binutils, GCC, and glibc. There are ports of LLVM/clang, QEMU, and OpenEmbedded; though those are a bit farther from upstream, as the toolchain stuff needs to come first. The patch simply adds "riscv{32,64}" to the list of arch tuples that Gentoo can understand, much like the GNU config patch -- the rest of the changes will stay in my overlay. I thought this was just the simplest way of getting crossdev up, and additionally once GNU gets upstreamed it should be all that's required to get a cross compiler running. Really the only reason I submitted this now is that this file gets overwritten on every "emerge --sync" and I don't want to put the eclass in my overlay because I always think of eclasses in overlays as being a bit fragile.
the tuples are fixed once they're merged into the GNU config project, but the kernel isn't fixed until it's merged into mainline ;) why does the kernel have two arch ports ? why isn't it just "riscv" for both ? similarly, i would avoid unique KEYWORDS here. "riscv" should be sufficient for both. we do this for everyone (other than x86/amd64, but the latter supports two ABIs now). so the code would simply be: + riscv*) echo riscv;;
(In reply to SpanKY from comment #3) > the tuples are fixed once they're merged into the GNU config project, but > the kernel isn't fixed until it's merged into mainline ;) > > why does the kernel have two arch ports ? why isn't it just "riscv" for > both ? There aren't two ports, there's just two arch names. There are both 32-bit and 64-bit variants of the RISC-V ISA, which are ABI incompatible (different register widths, among other things). The compiler tuples look like riscv64-unknown-linux-gnu riscv32-unknown-linux-gnu and when we want to make in Linux for headers (currently the only thing that uses this patch), it's expected that you do something like make ARCH=riscv64 install-headers and specifically NOT make ARCH=riscv install-headers We did it this way because it's the same way Tilera does it, and they're kind of the canonical port to copy for new architectures today. There you do "make ARCH=tilegx" or "make ARCH=tilepro" to get their different Linux targets. > similarly, i would avoid unique KEYWORDS here. "riscv" should be sufficient > for both. we do this for everyone (other than x86/amd64, but the latter > supports two ABIs now). I agree that there shouldn't be two KEYWORDS for RISC-V, but I wasn't aware that was tied to this toolchain ninja function. If this results in two different KEYWORDS then it's just straight-up wrong, sorry! > so the code would simply be: > + riscv*) echo riscv;; That's what I tried first, but then linux-headers does "make ARCH=riscv", which doesn't work. Ideally what I'd like to have is: riscv64-unknown-linux-gnu-gcc make ARCH=riscv64 configure --target=riscv64-unknown-linux-gnu KEYWORDS="riscv"
(In reply to Palmer Dabbelt from comment #4) i'm aware of the diff ISA's ... that's not what we're talking about here other arches have only one kernel source tree: arch/x86/ (i686 & x86_64) arch/powerpc/ (powerpc32 & powerpc64) arch/s390/ (s390 & s390x) arch/sparc/ (sparc32 & sparc64) arch/tile/ (tilegx & tilepro) when you install the kernel headers, they're exactly the same, so they can share the kernel $ARCH value. in the source, they check respective defines to figure out if the compilation env is 32bit or 64bit rather than providing two diff files. when the kernel build dir is used directly (e.g. to build a kernel module), the exact settings are taken from the .config, not from the $ARCH value. you can verify yourself: make headers_install ARCH=x86_64 INSTALL_HDR_PATH=$PWD/x86_64 make headers_install ARCH=i386 INSTALL_HDR_PATH=$PWD/i386 diff -ur -x '*.cmd' x86_64 i386 <no diff> make headers_install ARCH=tilegx INSTALL_HDR_PATH=$PWD/tilegx make headers_install ARCH=tilepro INSTALL_HDR_PATH=$PWD/tilepro diff -ur -x '*.cmd' tilegx tilepro <no diff> the same should for RISC-V. once the kernel sources are fixed, then there's no need for the toolchain eclass to know about riscv32 or riscv64.
(In reply to SpanKY from comment #5) > (In reply to Palmer Dabbelt from comment #4) > > i'm aware of the diff ISA's ... that's not what we're talking about here > > other arches have only one kernel source tree: > arch/x86/ (i686 & x86_64) > arch/powerpc/ (powerpc32 & powerpc64) > arch/s390/ (s390 & s390x) > arch/sparc/ (sparc32 & sparc64) > arch/tile/ (tilegx & tilepro) > > when you install the kernel headers, they're exactly the same, so they can > share the kernel $ARCH value. in the source, they check respective defines > to figure out if the compilation env is 32bit or 64bit rather than providing > two diff files. when the kernel build dir is used directly (e.g. to build a > kernel module), the exact settings are taken from the .config, not from the > $ARCH value. > > you can verify yourself: > make headers_install ARCH=x86_64 INSTALL_HDR_PATH=$PWD/x86_64 > make headers_install ARCH=i386 INSTALL_HDR_PATH=$PWD/i386 > diff -ur -x '*.cmd' x86_64 i386 > <no diff> > > make headers_install ARCH=tilegx INSTALL_HDR_PATH=$PWD/tilegx > make headers_install ARCH=tilepro INSTALL_HDR_PATH=$PWD/tilepro > diff -ur -x '*.cmd' tilegx tilepro > <no diff> > > the same should for RISC-V. once the kernel sources are fixed, then there's > no need for the toolchain eclass to know about riscv32 or riscv64. Yes, sorry about that -- you're definitely correct. So it looks like the correct thing to do is just to put riscv in toolchain-funcs.eclass, if you're OK with that? Sorry!
(In reply to Palmer Dabbelt from comment #6) so linux-headers does build if it gets ARCH=riscv ? or were you defining failure based on the ARCH you saw rather than it failing to build/install ? i've added the one line to toolchain-funcs: http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.130&r2=1.131
(In reply to SpanKY from comment #7) > (In reply to Palmer Dabbelt from comment #6) > > so linux-headers does build if it gets ARCH=riscv ? or were you defining > failure based on the ARCH you saw rather than it failing to build/install ? It always built, it's just that many things will default to riscv64 if passed riscv for historical reasons. I assumed that building at all with ARCH=riscv was wrong, as that would fail on riscv32. I had no way to test this, as I haven't gotten the whole toolchain building yet. As per your suggestion I verified that ARCH=riscv32 and ARCH=riscv64 install the same Linux headers, so just using ARCH=riscv is fine. > i've added the one line to toolchain-funcs: > http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.130&r2=1.131 Great, thanks a bunch!
sounds good. if you need more integration help, feel free to ask.
