Hi Jeff: You can use -r option (e.g. ./qemu-riscv64 -r 4.15) or set QEMU_UNAME environment variable to change the uname for qemu.
On Tue, Apr 10, 2018 at 6:50 AM, Jeff Law <l...@redhat.com> wrote: > On 04/09/2018 04:47 PM, Stef O'Rear wrote: >> On Mon, Apr 9, 2018 at 6:37 PM, Jeff Law <l...@redhat.com> wrote: >>> 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.. >> >> That error is produced by glibc if uname() returns a kernel version >> older than the oldest with arch support, which for riscv is 4.15.0. >> qemu-user does not fake uname(), so qemu-user for riscv will only work >> if the host is running 4.15.0 or newer. > Hmm, makes sense since the hosts are running 4.10-ish > > I'll hack around it somehow. I'd really like to add riscv64 to the > tester and don't want to mess around with kernel updates. > > Thanks, > jeff
