Re: GCC changes for Fedora + riscv64

[Kito Cheng <kito dot cheng at gmail dot com>]

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 <law@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 <law@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