On 04/09/2018 12:04 PM, Jim Wilson wrote: > On 04/08/2018 08:22 AM, Jeff Law wrote: >> On 03/31/2018 12:27 PM, Richard W.M. Jones wrote: >>> I'd like to talk about what changes we (may) need to GCC in >>> Fedora to get it working on 64-bit RISC-V, and also (more >>> importantly) to ask your advice on things we don't fully >>> understand yet. However, I don't know even what venue you'd >>> prefer to discuss this in. > > A discussion here is fine with me. I know of a few issues. > > I have a work-in-progress --with-multilib-list patch in PR 84797 but it > isn't quite right yet, and needs to work more like the patch in PR > 85142, which isn't OK to check in. > > There is a problem with atomics. We only have builtins for the ones > that can be implemented with a single instruction. Adding -latomic > unconditionally might fix it, but won't work for gcc builds and the gcc > testsuite unless we also add paths pointing into the libatomic build > dir. I'm also concerned that this might cause build problems, if we end > up trying to link with libatomic before we have built it. The simplest > solution might be to just add expanders for all of the missing atomics, > even if they require multiple instructions, just like how all of the > mainstream linux targets currently work. > > There is a problem with the linker not searching the right set of dirs > by default. That is more a binutils problem than a gcc problem, but the > linker might need some help from gcc to fix it, as the linker doesn't > normally take -march and -mabi options. > > There is a problem with libffi, which has RISC-V support upstream, but > not in the FSF GCC copy. This is needed for go language support. There > was also a dispute about go something naming, as to whether it should be > riscv64 or riscv, with one person doing a port choosing the former and > another person doing another port choosing the latter. > > Those are all of the Linux specific ones I can remember at the moment. I > might have missed some. Are you guys using qemu user mode emulation for testing purposes? When I've set up a suitable riscv64 rootfs and try to do anything nontrivial in it with qemu user mode emulation it immediately complains that my kernel is too old -- which is quite odd as I've got a dozen or so of these kinds of environments set up for testing which don't issue that complaint.
I'd like to avoid full system emulation just from a cost standpoint.. Jeff