Differential D23741
riscv: Set MACHINE_ARCH define based on TARGET_ARCH Authored by kp on Feb 18 2020, 12:58 PM. Tags None Referenced Files
Subscribers
Details
MACHINE_ARCH sets the hw.machine_arch sysctl, which bsd.cpu.mk uses to Set the define from the riscv makefile so that we correctly reflect our Sponsored by: Axiado
Diff Detail
Event TimelineComment Actions The previous version was an incomple fix. Happily we *can* rely on the __riscv_float_abi_soft define in userspace. Comment Actions I found the following excerpt in bsd.cpu.mk: .if ${MACHINE_CPUARCH} == "riscv"
.if ${MACHINE_ARCH:Mriscv*sf}
CFLAGS += -march=rv64imac -mabi=lp64
.else
CFLAGS += -march=rv64imafdc -mabi=lp64d
.endif
.endifSo we could instead check for the presence of hardware floating extensions using the following check in param.h: I think this would eliminate the need for the define in Makefile.riscv Comment Actions https://github.com/riscv/riscv-toolchain-conventions defines __riscv_float_abi_soft as well, so I don't know if that helps us.
I don't think so. We build the kernel without floating point support, so it'd always think it was a soft float version. Comment Actions I've had it explained to me by the LLVM folks that soft-float ABI != lack of hardware floating point. They also said that in general, we can rely on __riscv_flen to detect the presence of the "f" or "d" extensions (see this comment). I agree that the document you linked is under-specified for the case where these extensions are disabled. You're right that at the moment it doesn't matter which one we use for the check, __riscv_soft_float_abi or __riscv_flen.
You're right about this still being required, since the kernel gets its CFLAGS from kern.mk, not bsd.cpu.mk. I see that the riscv64 and riscv64sf kernels are built with identical march and mabi flags, which I think is a separate problem. Ideally, the riscv64 target would be built with -march=rv64imafdc -mabi=lp64 so that floating point instructions can be used within the kernel (e.g. during context switch), but the soft-float ABI is still used generally. To ensure riscv64sf can be run on cores that actually lack hardware floating point support, it should be compiled with -march=rv64imac -mabi=lp64, and the FPE kernel option should be removed/disabled. If this is done, we could rely on checking __riscv_flen alone to determine MACHINE_ARCH for both kernel and userland. I'm happy with your fix as-is, but we could revisit it if/when the above is addressed.
Comment Actions I suspect that we just need to set CFLAGS right in Makefile.riscv rather than this hack.
Comment Actions There's certainly still something missing. When I build with make TARGET_ARCH=riscv64sf it builds with MACHINE_ARCH = riscv64, and that breaks ports builds (because we set the wrong flags). I've tried this: diff --git a/sys/conf/Makefile.riscv b/sys/conf/Makefile.riscv index a29390f2e85..183fa6dd448 100644 --- a/sys/conf/Makefile.riscv +++ b/sys/conf/Makefile.riscv @@ -46,8 +46,6 @@ SYSTEM_LD= @${LD} -N -m ${LD_EMULATION} -Bdynamic -T ${LDSCRIPT} ${_LDFLAGS} \ CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls .endif -CFLAGS += -DMACHINE_ARCH=\"${TARGET_ARCH}\" - # hack because genassym.c includes sys/bus.h which includes these. genassym.o: bus_if.h device_if.h diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk index 0737f420321..40d9f24c345 100644 --- a/sys/conf/kern.mk +++ b/sys/conf/kern.mk @@ -306,4 +306,5 @@ LD_EMULATION_powerpc= elf32ppc_fbsd LD_EMULATION_powerpcspe= elf32ppc_fbsd LD_EMULATION_powerpc64= elf64ppc_fbsd LD_EMULATION_riscv64= elf64lriscv +LD_EMULATION_riscv64sf= elf64lriscv LD_EMULATION=${LD_EMULATION_${MACHINE_ARCH}} diff --git a/sys/riscv/conf/DEFAULTS b/sys/riscv/conf/DEFAULTS index 94c6bf283c4..c06a3af22f4 100644 --- a/sys/riscv/conf/DEFAULTS +++ b/sys/riscv/conf/DEFAULTS @@ -3,7 +3,7 @@ # # $FreeBSD$ -machine riscv riscv64 +machine riscv riscv64sf # Pseudo devices. device mem # Memory and kernel memory devices diff --git a/sys/riscv/include/param.h b/sys/riscv/include/param.h index a017ef20f6f..94e18c58041 100644 --- a/sys/riscv/include/param.h +++ b/sys/riscv/include/param.h @@ -46,12 +46,8 @@ #define MACHINE "riscv" #endif #ifndef MACHINE_ARCH -#ifdef __riscv_float_abi_soft -#define MACHINE_ARCH "riscv64sf" -#else #define MACHINE_ARCH "riscv64" #endif -#endif #ifdef SMP #ifndef MAXCPU While the LD_EMULATION_riscv64 at least lets it build (without it it doesn't), sysctl hw.machine_arch is still riscv64. I'm not sure what you mean by this:
What do we need to set in CFLAGS? Comment Actions During the actual build, MACHINE_ARCH is risc64sf for a TARGET_ARCH of riscv64sf.
This is still needed, but with MACHINE_ARCH instead of TARGET_ARCH. I was mistaken you needed to remove it completely. In the future, I'd like to see that, but currently something is misaligned with the ABI and what's tested for in param.h. Once that's fixed, then this can be removed.
This is a good idea.
This will cause the generated Makefile to have a MACHINE_ARCH=riscv64sf as it's second line. Once upon a time, we talked about being able to override machine, but I'm not sure how far we got with that. Ideally, you'd have a GENERICSF that is just include GENERIC machine riscv riscv64sf and then that kernel would be the correct MACHINE_ARCH...
This will cause it to always be riscv64. This change is almost certainly wrong
Yea, by the time you get around to setting an ld emulation, it's too late to affect the kernel .o's that have been built already.
I mean you need to include the right -march or other flag in CFLAGS so that the kernel is built with the same riscv64sf ABI as userland. Comment Actions With a hack to config, I have the following GENERICSF include GENERIC machine riscv riscv64sf and get a kern_mib.o that had riscv64sf in it (before the change, it was absent). Which should get you want you need in the short term. Comment Actions I've committed the config hacks and created GENERICSF that compiles as well as GENERIC ld: warning: Non-zero addend in R_RISCV_PCREL_LO12 relocation to accf_http.kld:(soishttpconnected) is ignored ld: error: R_RISCV_PCREL_LO12 relocation points to accf_http.kld:(soishttpconnected) without an associated R_RISCV_PCREL_HI20 relocation ld: warning: Non-zero addend in R_RISCV_PCREL_LO12 relocation to accf_http.kld:(soparsehttpvers) is ignored ld: error: R_RISCV_PCREL_LO12 relocation points to accf_http.kld:(soparsehttpvers) without an associated R_RISCV_PCREL_HI20 relocation *** [accf_http.ko.full] Error code 1 | ||||||||||||||||||||||||||||||||||||||||||||||