svn commit: r358247 - in head/sys: conf riscv/include

[Warner Losh]

On Mon, Feb 24, 2020 at 11:08 AM John Baldwin <jhb at freebsd.org> wrote:

> On 2/22/20 5:23 AM, Kristof Provost wrote:
> > Author: kp
> > Date: Sat Feb 22 13:23:27 2020
> > New Revision: 358247
> > URL: https://svnweb.freebsd.org/changeset/base/358247
> >
> > Log:
> >   riscv: Set MACHINE_ARCH correctly
> >
> >   MACHINE_ARCH sets the hw.machine_arch sysctl in the kernel. In
> userspace
> >   it sets MACHINE_ARCH in bmake, which bsd.cpu.mk uses to configure the
> >   target ABI for ports.
> >
> >   For riscv64sf builds (i.e. soft-float) that needs to be riscv64sf, but
> >   the sysctl didn't reflect that. It is static.
> >
> >   Set the define from the riscv makefile so that we correctly reflect our
> >   actual build (i.e. riscv64 or riscv64sf), depending on what TARGET_ARCH
> >   we were built with.
> >
> >   That still doesn't satisfy userspace builds (e.g. bmake), so check if
> >   we're building with a software-floating point toolchain there. That
> >   check doesn't work in the kernel, because it never uses floating point.
> >
> >   Reviewed by:        philip (previous version), mhorne
> >   Sponsored by:       Axiado
> >   Differential Revision:      https://reviews.freebsd.org/D23741
>
> I actually think this is kind of busted as the kernel is always the same,
> and we have the same problem on MIPS which also already does this wrong.
> I think instead we should treat soft-float as an alternate ABI (though
> very light weight as it doesn't need a separate syscall handler, etc.) and
> make the sysctl handler smart enough to return the right value based on the
> ELF header of the binary.
>
> I saw the later followup commit to add GENERICSF and I think that is
> possibly
> even farther down the wrong path.  The kernel is _always_ soft-float in
> terms
> of the ABI it is built with.  However, kernel with FPE support can run
> binaries
> with either ABI.  It's true that on RISC-V there is not a nice way to
> detect
> if the FPU is present (I haven't looked at OpenSBI, but the SBI used with
> bbl
> doesn't provide misa to S-mode to know if it is present or not).  You could
> just try to execute an FPU instruction during boot to see if you get an
> illegal instruction fault (subject to your SBI choosing to emulate that).
>

We talked about this on IRC, and here's a summary of my understanding

Short term, we'll keep GENERICSF so that we can build ports correctly. I'll
post a couple of fixes to it, but generally it will stay as is for the
short term.

Longer term, we need to formalize the many to many relationships between
userland ABI and kernel ABI in a number of ways. We need them for MIPS as
well as CHERI work. To that end, we'll move for riscv to having a single
kernel that can execute multiple ABIs. we'll update the hw.machine_arch to
return the ABI of the binary that's running. We'll also make sure that we
make the FPU stuff more dynamic in some way. Here 'we' is hazily defined,
but I think it's mostly John :). There will also need to be some minor
tweaks to the build system that I'm investigating (things mostly work
today, but there are times that we get mismatches that matter and go
undetected I think -- which is what I'm looking into).

Warner