Re: Future of 32-bit platforms (including i386) [armv7 specific note]

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