Date: Thu, 1 Apr 2021 00:45:44 +0200 From: Robert Clausecker <fuz@fuz.su> To: freebsd-arm@freebsd.org Subject: Re: 32-bit executables on aarch64? Message-ID: <YGT7mHl1tXwmdXRn@fuz.su> In-Reply-To: <BDE56DE3-976D-4564-8ABD-D4D218C670F7@yahoo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mark, 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. 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. 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... But surely, lib32 support for arm64 would be even better in this regard. Yours, Robert Clausecker Am Wed, Mar 31, 2021 at 03:02:27PM -0700 schrieb Mark Millard: > > > On 2021-Mar-31, at 14:12, Robert Clausecker <fuz at fuz.su> wrote: > > > Hi Mark, > > > > 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. > > > > > > 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. > > If such is needed, you can still buildworld, buildkernel, > and build ports in a faster/more-RAM environment. > > 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.) > > 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= 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. > > Building armv7 ports on aarch64 would always involve a > chroot (possibly implicitly via poudriere's cross build > way of working for such). > > 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. > > > > > Am Wed, Mar 31, 2021 at 11:05:45AM -0700 schrieb Mark Millard: > >> > >> On 2021-Mar-31, at 10:46, Robert Clausecker <fuz at fuz.su> wrote: > >> > >>> Hi Thomas, > >>> > >>> 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. > >> > >> aarch64 FreeBSD supports having an armv7 world installed > >> in a directory tree for use with chroot. > >> > >> I've a separate reply to the original submittal showing > >> a use of such. > >> > >> aarch64 FreeBSD lacks lib32 for more direct execution > >> of armv7 FreeBSD code without involving a chroot use (or > >> qemu use or other such). > >> > >>> 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. > >>> > >>> Yours, > >>> Robert Clausecker > >>> > >>> Am Wed, Mar 31, 2021 at 12:55:59PM -0400 schrieb Thomas David Rivers: > >>>> > >>>> I'm playing around with a (rather-old now) 13.0-pre-pre-pre release > >>>> on Raspberry PI 4B. > >>>> > >>>> 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. > >>>> > >>>> I installed the gcc V9 port and it said the same thing. > >>>> > >>>> This begged the question, is there no support of 32-bit ARM (armv7) > >>>> executables in the aarch64 environment? > >>> > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YGT7mHl1tXwmdXRn>