Date: Sun, 23 Feb 2020 12:37:14 -0700 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r358262 - head/sys/conf Message-ID: <66fe6ff74daea4320dc1c89ca36dbad964945081.camel@freebsd.org> In-Reply-To: <202002231904.01NJ4FmD046982@repo.freebsd.org> References: <202002231904.01NJ4FmD046982@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2020-02-23 at 19:04 +0000, Warner Losh wrote: > Author: imp > Date: Sun Feb 23 19:04:15 2020 > New Revision: 358262 > URL: https://svnweb.freebsd.org/changeset/base/358262 > > Log: > Use MACHINE_ARCH instead of TARGET_ARCH > > TARGET_ARCH is only for use in Makefile.inc1 contexts. MACHINE_ARCH is the > preferred thing to set. Makefile.inc1 sets MACHINE_ARCH in the cross build > case, and make sets it in the native build case. This will fix anybody doing a > native build. Add a comment for why we have to do this dance so when/if the > problem with CFLAGS is fixed for the kernel this workaround can be removed. > I suddenly wonder: why does the kernel build need to know about the float ABI if we don't use floating point in the kernel? If it's about whether to include support for the floating point hardware (save/restore context at the userland boundary, etc), then shouldn't that be controlled with a kernel config option or device statement like it is on other arches? If the kernel actually is being compiled with different -march= to generate hardfloat instructions/register usage/etc, then shouldn't there be some compiler-defined macro to indicate that? (A quick search says that __riscv_float_abi_soft may be that macro.) -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66fe6ff74daea4320dc1c89ca36dbad964945081.camel>