Date: Fri, 26 May 2023 00:03:30 +0000 From: Brooks Davis <brooks@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Brooks Davis <brooks@freebsd.org>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Future of 32-bit platforms (including i386) [armv7 specific note] Message-ID: <ZG/3UosCb3JzhyAt@spindle.one-eyed-alien.net> In-Reply-To: <17656C7B-9211-42A0-9D71-954FE6FE424B@yahoo.com> References: <17656C7B-9211-42A0-9D71-954FE6FE424B.ref@yahoo.com> <17656C7B-9211-42A0-9D71-954FE6FE424B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 25, 2023 at 04:53:00PM -0700, Mark Millard wrote: > Brooks Davis <brooks_at_freebsd.org> wrote on > Date: Thu, 25 May 2023 17:48:28 UTC : > > > On Wed, May 24, 2023 at 07:55:15AM -0700, Mark Millard wrote: > > > John Baldwin <jhb_at_FreeBSD.org> wrote on > > > Date: Tue, 23 May 2023 23:46:51 UTC : > > > > > > . . . > > > > > > (Prompted by manu's > > > https://lists.freebsd.org/archives/freebsd-arch/2023-May/000454.html .) > > > > > > I'll note that armv7 does not now have lib32 support > > > for aarch64's that support EL0 AArch32. That would be > > > a development effort. > > > > > > armv7 can be used via the likes of chrooting into a > > > armv7 world's directory tree for such aarch64's. That > > > is what I do on aarch64 for armv7. > > > > > > > One question for this is if we think we will have sufficient developer > > > > resources to maintain armv7 kernels for the life of stable/15. > > > > > > Sufficient developer support to get lib32 supporting > > > armv7 in place and keep it operational? > > > > It's not too hard (but I did make it harder by requiring that lib32 be > > build via -m32 on an aarch64 sysroot.) Someone would need to get -m32 > > working well enough to meet the needs of lib32. I'd suggest looking > > for i386 ifdefs in the x86 and amd64 trees as a start. > > Just about -m32 . . . > > share/mk/src.opts.mk has long had: > > # aarch64 needs arm for -m32 support. > .elif ${__T} == "aarch64" && ${__llt:Marm*} != "" > __DEFAULT_DEPENDENT_OPTIONS+= LLVM_TARGET_ARM/LLVM_TARGET_AARCH64 > > that, if I understood right, meant that aarch64 also had > arm targeting enabled by default and such was sufficient > for -m32 to be used. > > This was put in place in the 2018-Jun-27 commit described > by: > > QUOTE > LLVM_TARGET_ALL: Default LLVM_TARGET_ARM on for aarch64. > This is needed for -m32 support which is used in the kernel cloudabi32 module. Tweak the style to make it easier to understand. > END QUOTE > > So it seems that -m32 had been already in use in some > way. > > May be this is not about -m32 itself but about having > more FreeBSD code able to handle -m32 being enabled? > If so, a bunch of commits from 2022-Jun-13 that are > titled like "amd64: -m32 support for machine/..." > might be some of the "x86 and amd64 trees" that you > are referencing? Yeah, that's what I'm talking about. For -m32 to work you need headers that do the right thing when whatever defines signify -m32 are set. In practice this mostly means diffing arm/include and arm64/include and updating arm64. Basically it's annoying ifdefs. The good news is that aarch64 and armv7 should have fewer differences than amd64 and i386 due to 64-bit types being strongly aligned and time_t being 64-bit. -- Brooks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZG/3UosCb3JzhyAt>