Date: Wed, 31 Mar 2021 16:36:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Clausecker <fuz@fuz.su> Cc: freebsd-arm@freebsd.org Subject: Re: 32-bit executables on aarch64? Message-ID: <1BF8C073-2913-4AA9-83DB-64CD3791147A@yahoo.com> In-Reply-To: <YGT7mHl1tXwmdXRn@fuz.su> References: <202103311655.12VGtx3T036893@office.dignus.com> <YGS1exSvCS7sFGn%2B@fuz.su> <E1269F39-41F2-40F7-B8F5-2E39349B9C3F@yahoo.com> <YGTlpD7ph2fPlaM6@fuz.su> <BDE56DE3-976D-4564-8ABD-D4D218C670F7@yahoo.com> <YGT7mHl1tXwmdXRn@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Mar-31, at 15:45, Robert Clausecker <fuz at fuz.su> wrote: > The intent is to test and develop software that only runs on > armv7 (specifically, Mecrisp Stellaris, a Forth system written > in ARM assembly). This is best done natively. >=20 > It's actually kinda annoying that no binary release tarballs > are provided for armv7, so setting up the jail involves an > annoying make world step. For amd64 jails, I can just unpack > the binary tarballs and fix the configuration and I'm good to go. >=20 > The problem with the armv7 machine was that it didn't have > enough RAM to make world (and setting up swap on an SD card is > a surefire way to send it to an early grave, so I'd rather avoid > that). Ended up having to swap over NFS and wait more than a > week for make world to complete. And that only because there is > no other way to upgrade the machine remotely. If only there were > binary release tarballs... >=20 > But surely, lib32 support for arm64 would be even better in this > regard. [There is no lib32 support, only the chroot support. (jail use may well inherit such chroot properties and also work. I've never explicitly used a jail.)] There are armv7 tarballs around --but exactly which stable/13 or main or whatever commits will happen to be available is more of a grab bag, depending on what the ci.freebsd.org builds happened to do. Example 2021-Mar-31 stable/13 armv7 .txz files are at: = https://artifact.ci.freebsd.org/snapshot/stable-13/a25c17022e2d6344dcbc619= 2af276d2798d76d44/arm/armv7/ Example 2021-Mar-31 main armv7 .txz files are at: = https://artifact.ci.freebsd.org/snapshot/main/006a01374f59b839ca1c900efd27= 4a3b92044b15/arm/armv7/ Multiple builds for the same day are possible. It is common for a give commit that only some of the architectures end up with a build. So finding what is available for a given architecture is messy. But it may well be worth the effort if you do not require releng or weekly snaphot builds or other special examples. Such .txz areas tend to stick around for much of a year. So once you have found one that you are willing to use, it should still be around to re-find for a while. I tend to sort the browser display for looking to find something of use, since git hashes do not sort usefully. For example: https://artifact.ci.freebsd.org/snapshot/main/?C=3DM&O=3DD Of course the paths for pre-git look different in some respects but they are there, such as: https://artifact.ci.freebsd.org/snapshot/main/r368818/arm/armv7/ > Yours, > Robert Clausecker >=20 > Am Wed, Mar 31, 2021 at 03:02:27PM -0700 schrieb Mark Millard: >>=20 >>=20 >> On 2021-Mar-31, at 14:12, Robert Clausecker <fuz at fuz.su> wrote: >>=20 >>> Hi Mark, >>>=20 >>> This is news to me. Excellent news! I can't say how grateful I am >>> for having this pointed out by you. Can now go ahead and throw out >>> my dedicated armv7 test machine which has caused me a lot of >>> head aches with world builds and all that. >>>=20 >>>=20 >>=20 >> Somewhat depends on the type/intent of the testing activity. >> If testing the armv7 kernel is part of the point, then >> building might be done on the likely faster (and more RAM >> across processes) aarch64 environment in the chroot and >> some testing there as well. But for armv7 kernel testing, >> it would take use in an environment that was running actual >> armv7 FreeBSD kernel and world. >>=20 >> If such is needed, you can still buildworld, buildkernel, >> and build ports in a faster/more-RAM environment. >>=20 >> One way to have an armv7 chroot available in aarch64 is to >> have the media that is used for the actual armv7 system >> temporarily connected to the aarch64 system and mount the >> file system and chroot into it to do the builds and >> installs and such. (Might not be as easy if the armv7 >> system context is split into multiple mount points.) >> Later exit the chroot, dismount, connect back up to the >> armv7 system, and boot. (I'm not addressing special >> handling of u-boot or an msdos file system's contents >> or the like here.) >>=20 >> As for installkernel installworld, etcupdate, etc. if >> instead a cross build was made outside a chroot, the >> installs and such can target a mounted file system >> (DESTDIR=3D and the like is involved). This also avoids >> some of the technical issues that can be involved for >> live updating the same system that is running. >>=20 >> Building armv7 ports on aarch64 would always involve a >> chroot (possibly implicitly via poudriere's cross build >> way of working for such). >>=20 >> It is rare that I build for armv7 on an armv7. It is also >> rare that I build for aarch64 on slower aarch64 machines. >> A similar point was always been true for my historical >> powerpc64 and 32-bit powerpc activities. >>=20 >>>=20 >>> Am Wed, Mar 31, 2021 at 11:05:45AM -0700 schrieb Mark Millard: >>>>=20 >>>> On 2021-Mar-31, at 10:46, Robert Clausecker <fuz at fuz.su> wrote: >>>>=20 >>>>> Hi Thomas, >>>>>=20 >>>>> Unfortunately, there is no support for running armv7 executables >>>>> on arm64, though it would technically be possible to implement. >>>>> I myself would really like to have this sort of thing but I lack >>>>> the knowledge to have it. Perhaps someone feels adventurous >>>>> enough to look into implementing support for this sort of thing. >>>>=20 >>>> aarch64 FreeBSD supports having an armv7 world installed >>>> in a directory tree for use with chroot. >>>>=20 >>>> I've a separate reply to the original submittal showing >>>> a use of such. >>>>=20 >>>> aarch64 FreeBSD lacks lib32 for more direct execution >>>> of armv7 FreeBSD code without involving a chroot use (or >>>> qemu use or other such). >>>>=20 >>>>> For historical reasons, the i386 and amd64 ports of gcc and clang >>>>> have a largely shared code base and are essentially the same port. >>>>> So options -m32, -m64 can be used to switch between them. The = same >>>>> is not possible for armv7 and arm64 which are distinct ports with >>>>> little to no shared backend code. Consider using -target armv7 >>>>> instead. >>>>>=20 >>>>> Yours, >>>>> Robert Clausecker >>>>>=20 >>>>> Am Wed, Mar 31, 2021 at 12:55:59PM -0400 schrieb Thomas David = Rivers: >>>>>>=20 >>>>>> I'm playing around with a (rather-old now) 13.0-pre-pre-pre = release >>>>>> on Raspberry PI 4B. >>>>>>=20 >>>>>> I was naively thinking I could just use -m32 to create a 32-bit >>>>>> executable... but the LLVM there promptly told me it didn't = recognize >>>>>> -m32. >>>>>>=20 >>>>>> I installed the gcc V9 port and it said the same thing. >>>>>>=20 >>>>>> This begged the question, is there no support of 32-bit ARM = (armv7) >>>>>> executables in the aarch64 environment? >>>>>=20 >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1BF8C073-2913-4AA9-83DB-64CD3791147A>