GCC changes for Fedora + riscv64

[Jeff Law]

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