Date: Sun, 23 Feb 2020 13:21:32 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r358262 - head/sys/conf Message-ID: <CANCZdfrkPEJYt8HtzKW32J%2Bpy-Yq=Jnsf1UHPejGMXQqN9ZDRA@mail.gmail.com> In-Reply-To: <66fe6ff74daea4320dc1c89ca36dbad964945081.camel@freebsd.org> References: <202002231904.01NJ4FmD046982@repo.freebsd.org> <66fe6ff74daea4320dc1c89ca36dbad964945081.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 23, 2020, 12:37 PM Ian Lepore <ian@freebsd.org> wrote: > 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? > This is so the sysctl that make uses returns the right thing. 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.) > The code review for the prior change explored that. This change just documented the prior change and used the right make variable. I honestly think this is a short term hack until other issues are settled. I justed wanted the hack to be right. Warner -- Ian > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrkPEJYt8HtzKW32J%2Bpy-Yq=Jnsf1UHPejGMXQqN9ZDRA>