From nobody Mon Dec 18 07:16:50 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Strjj2g0Nz541yw for ; Mon, 18 Dec 2023 07:16:57 +0000 (UTC) (envelope-from samm@freebsd.org) Received: from reindeer.net-art.cz (reindeer.net-art.cz [IPv6:2001:15e8:110:513c::1]) (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 (2048 bits) client-digest SHA256) (Client CN "reindeer.net-art.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Strjh3MtQz4qbw for ; Mon, 18 Dec 2023 07:16:56 +0000 (UTC) (envelope-from samm@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by reindeer.net-art.cz (Postfix, from userid 65534) id 724C95F315; Mon, 18 Dec 2023 07:16:55 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on reindeer X-Spam-Level: X-Spam-Status: No, score=-1.2 required=10.0 tests=BAYES_00,SPF_HELO_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.2 Received: from owl.net-art.cz (owl.net-art.cz [IPv6:2a03:6920:0:10::101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "owl.net-art.cz", Issuer "R3" (not verified)) by reindeer.net-art.cz (Postfix) with ESMTPS id 1F7DA5EEAD; Mon, 18 Dec 2023 07:16:54 +0000 (GMT) Received: from [::1] (account samm@net-art.cz HELO webmail.net-art.cz) by owl.net-art.cz (CommuniGate Pro SMTP 6.1.20) with ESMTPA id 2210458; Mon, 18 Dec 2023 08:16:50 +0100 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 18 Dec 2023 08:16:50 +0100 From: Alex Samorukov To: Mark Millard Cc: freebsd-arm Subject: Re: problems on FreeBSD14 on armv6 board (RPI1-B) In-Reply-To: References: <2025707260.15114.1702739060451@localhost> <29274DE1-57D2-45D3-BEB0-CBCF7C70681D@yahoo.com> <3E19FD5D-BC1A-4BA0-970F-BF195D8F7470@yahoo.com> <7115fd399a58084266b71ecfbd400334@freebsd.org> Message-ID: X-Sender: samm@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24806, ipnet:2001:15e8::/32, country:CZ] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Strjh3MtQz4qbw On 2023/12/18 01:41, Mark Millard wrote: ch to poudrier to make it possible [1], but it seems that upstream does not care about patches anymore. >> >> Regarding bug 256132 - so far i cant find that it impacting my builds >> at all - binaries are running well. > > Is all that testing only on an armv6-only processor? Testing on armv7 > or aarch64-that-supports-armv7 would execute code that armv6 would > not. Testing was done on armv6 CPI, RPI1-B board I have. Of course i was not testing everything, as it hard to expect from 512Mb 1CPU board to run Java or Firefox. But at least things like boost, gdb, domoticz, busybox, nginx, ebusd and +-10 other ports I tried are working fine. Now i am running bulk -a to do more extensive checks. > >> I could assume that some configure scripts could try to check (and >> enable) some flags for armv7 while building, but I think the chances >> are very low and it could be handled on ad-hoc basis. > > What have you done to avoid armv7 specific defaults from being used, > instead causing armv6 defaults? I think it should be done out of the box. As I am using chroot from armv6 - the compiler by default should generate armv6 code, otherwise it would be cross-compilation which you have to specify explicitly. Also, it probably will be a good idea to add corresponding `-m` flags to default C/CXX flags. What I need to check - is if llvm* compiled from ports is still assuming that the target is the correct one. I will do that once my bulk run is complete and will let you know the results. I also think that this situation is not that much different from i386 compilation on amd64, potentially some "too smart" configure scripts may detect extensions that are not supposed to be present on i386 and build a broken binary, but in 90+% cases, it should not be the thing as compiler will have default target set correctly. > >> Please correct me if I am missing something. Thank you, Oleksij > > I'll note that I've never done such "armv6-only processor" testing. > I'll not have access to any FreeBSD arm6, arm7, or aarch64 contexts > until after something like 2024-Jan-01. Anyway, thank you for your help. Maybe I will get +1 board (they are very cheap now anyway) to set up as a playground and testing. Especially because we may get a very similar situation at some point with v8+ arms on 64-bit :)