Re: Running armv7 on aarch64

From: Kristof Provost <kp_at_FreeBSD.org>
Date: Wed, 19 Oct 2022 08:58:03 UTC
On 18 Oct 2022, at 20:18, Kristof Provost wrote:
> On 18 Oct 2022, at 19:38, Mark Millard wrote:
>> On 2022-Oct-18, at 09:53, Kristof Provost <kp@FreeBSD.org> wrote:
>>> It’s not quite clear to me how this is supposed to work (now). On amd64 there’s a separate /libexec/ld-elf32.so.1, which we don’t have on aarch64. Is it supposed to be built?
>>>
>>> It’s broken on ab9293239c7d and e03b7883e97c at the very least.
>>
>> [I'm ignoring qemu, which I do not use. The below is from
>> a Cortex-A72 aarch64 context that can execute Cortex-A7
>> armv7 code as well. Have you been using qemu?]
>>
>> Historically I've only been able to execute armv7 FreeBSD
>> code on aarch64 FreeBSD via using the likes of, say,
>> chroot'ing into an installed armv7 world in a directory
>> tree that I created for such. (I manually split some
>> liong-lineouptut for readabilty.)
>>
> Thanks for that!
>
> That’s at least part of what I was missing. Long story short, I’m trying to build an armv7 image on an aarch64 machine, and having issues with poudriere. I figured I was going to simplify things by executing the armv7 binary directly (to debug), but that’s missing a few steps and had me chasing down the wrong track.
>
> I can’t chroot into that armv7 jail, I still see errors like this:
>
>     (kp@freebsd_current)  /usr/local/poudriere/data/.m/main-pfSense_factory_ports_plus_devel/ref % sudo chroot .
>     ELF binary type "9" not known.
>     ELF binary type "9" not known.
>     chroot: /bin/sh: Exec format error
>
> But at least I think I’m looking in the correct direction now.
>
For those playing along at home, I believe I now understand why the above doesn’t work.
This is a VMWare Fusion VM (preview of 09/22), and it appears to no longer support 32-bit arm.

FreeBSD refuses to start a 32-bit arm binary due to the check in elf32_arm_abi_supported(). It reads the id_aa64pfr0_el1 special register, which doesn’t indicate 32-bit support. It lists 0x1101000011111111 as a value now.

Simply removing the check allows the 32-bit binary to execute, but that crashes the VM, so isn’t very useful.

Best regards,
Kristof