Re: git: 60f098f84119 - main - arch: Update to remove armv6

From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 15 Jul 2024 17:08:53 UTC
Ed Maste <emaste_at_freebsd.org> wrote on
Date: Mon, 15 Jul 2024 13:03:16 UTC :

> On Sun, 14 Jul 2024 at 02:00, Warner Losh <imp@freebsd.org> wrote:
> >
> > .Dv aarch64
> > will support execution of
> > -.Dv armv6
> > -or
> > .Dv armv7
> > binaries if the CPU implements
> > .Dv AArch32
> > -execution state, however older arm binaries aren't supported.
> > +execution state, however older arm binaries are not supported by
> > +.Fx .
> 
> Do older 32-bit Arm userland binaries actually not work? Would
> "support execution of 32-bit Arm binaries if the CPU implements the
> AArch32 execution state" be accurate?


# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #6 main-n271165-cb18ba9df52d-dirty: Fri Jul 12 11:09:16 PDT 2024     root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500020 1500020

# sysctl kern.supported_archs
kern.supported_archs: aarch64 armv7

As I understand that "armv7" is historically
tied to the likes of (shown via readelf):

Notes at offset 0x000001ac with length 0x00000064:
  Owner         Data size       Description
  FreeBSD       0x00000006      NT_FREEBSD_ARCH_TAG
   Arch tag: armv7

and, for example, attempting to use a file with
an armv6 tag would be rejected as not supported
historically. Similarly for armv5 and armv4 and
the like.

One had to modify source code to have
kern.supported_archs list, say, armv6 instead of
armv7. I helped someone do that once so that
they could poudriere bulk to build armv6 on
aarch64 by picking which kernel to boot (normal
vs. one with armv6 instead).

FreeBSD does not have support for having a longer
list of alternatives, say:

aarch64 armv7 armv6

Such would be a bigger source code change.

I think such is part of what Warner is referring
to, even if the other aspects of any of
armv6/armv5/armv4/... kernel support were left in
place. (No claim such has or will be left in
place.)

===
Mark Millard
marklmi at yahoo.com