From owner-freebsd-arm@freebsd.org Wed Mar 31 23:49:02 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F2B4C5B4F7A for ; Wed, 31 Mar 2021 23:49:02 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9jhG6PH1z4p2F for ; Wed, 31 Mar 2021 23:49:02 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id CDD3ED70C for ; Wed, 31 Mar 2021 23:49:02 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: by mail-yb1-f182.google.com with SMTP id 8so22987674ybc.13 for ; Wed, 31 Mar 2021 16:49:02 -0700 (PDT) X-Gm-Message-State: AOAM5338dvgc8K+qwDBpcKwPxhZNtyS8hnSJfUOF3kG7m+OW8Xdf57IX oTbdpxFAc5RK4pfPw0HNBAJTtndCheBPm3cZ4qM= X-Google-Smtp-Source: ABdhPJxPptIXne5KM5xxjtD3zTz76jcWcNuvZeRJhM8zhUtY5QVVxXGEakhk3DTDBjLAq+rTZ8FOgLuYmuVZt5Ki2uk= X-Received: by 2002:a25:3854:: with SMTP id f81mr8049867yba.466.1617234542311; Wed, 31 Mar 2021 16:49:02 -0700 (PDT) MIME-Version: 1.0 References: <202103311655.12VGtx3T036893@office.dignus.com> In-Reply-To: From: Mitchell Horne Date: Wed, 31 Mar 2021 20:48:50 -0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 32-bit executables on aarch64? To: Robert Clausecker Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2021 23:49:03 -0000 On Wed, Mar 31, 2021 at 7:45 PM Robert Clausecker wrote: > > 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. > This issue about lack of distribution sets for armv7 has come up a couple of times. It wouldn't take much to start producing them officially, so I plan to submit a patch for this once re@ is done with the 13.0 release. Cheers, Mitchell > 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 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 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 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"