On Sun, 30 Apr 2017 16:38:35 PDT (-0700), jos...@codesourcery.com wrote: > On Sat, 29 Apr 2017, Richard Biener wrote: >> On April 29, 2017 3:59:27 AM GMT+02:00, Palmer Dabbelt <pal...@dabbelt.com> >> wrote: >> >We've been telling people that "riscv32-*" and "riscv64-*" are exactly >> >the same toolchain aside from defaults for "-march" and "-mabi", but it >> >appears we were lying. As far as I can tell, binutils doesn't support >> >64-bit targets when it has been configured for a 32-bit target. This >> >seems to be an upstream limitation that we can't fix in the RISC-V >> >port. >> >This means that building the toolchain with "--with-arch=rv32i >> >--enable-multilib" will fail when building the 64-bit multilibs. >> > >> >This patch adds two new multilib target fragments that don't add the >> >64-bit multilibs. This fixes the build, but has the disadvantage of >> >making our 32-bit and 64-bit toolchains very different. >> >> PowerPC for 32bit can use powerpc64 as target and enable 32bit code-gen >> by default at configure time. Maybe this is an option for riscv as >> well.
I think we already support this as well: you can build RISC-V with "--target=riscv64-*" and "--with-isa=rv32g" which would build the 64-bit toolchain that defaults to a 32-bit target. We can (and pretty much always do, which is why this bug went unnoticed) generate 32-bit objects using our 64-bit toolchain. The bug here is that a LD that's built with "--target=riscv32*" can't handle 64-bit ELFs > Specifically, in such cases the GCC configure option is > --enable-target=all to enable 64-bit multilibs for a default-32-bit > target, and the binutils/GDB configure option is --enable-64-bit-bfd. But > you can also make a binutils/GDB target include 64-bit support > unconditionally without requiring --enable-64-bit-bfd. Do you happen to know how to do that (enable 64-bit BFDs in a 32-bit binutils build)? I'd prefer to have the riscv32 and riscv64 ports the same if possible, but poked around a bit and couldn't find a way to do it. If you just know some other port does this then I can probably figure it out from there. I'd hoped that submitting this patch would lead to someone telling me a better way to do it :).
