Date: Mon, 23 Sep 2019 14:31:01 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, Peter Jeremy <peter@rulingia.com> Cc: freebsd-arm@freebsd.org Subject: Re: ARM programs expecting misspelt __ARM_ARCH_6ZK__ Message-ID: <7e88e9e6280b81ae1327389fdd1f8298007df493.camel@freebsd.org> In-Reply-To: <CANCZdfr0v6jQ_G8EEGxjUehz8LUk=Rner9BO-XhTcc4=QcTAHQ@mail.gmail.com> References: <20190921081649.GM97181@server.rulingia.com> <CANCZdfr0v6jQ_G8EEGxjUehz8LUk=Rner9BO-XhTcc4=QcTAHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2019-09-21 at 11:55 +0200, Warner Losh wrote: > On Sat, Sep 21, 2019, 10:17 AM Peter Jeremy <peter@rulingia.com> wrote: > > > When GCC introduced support for the ARMv6KZ architecture, it misspelt it > > as ARMv6ZK. This only affects arm1176jz-s and arm1176jzf-s but, > > unfortunately, this includes the BCM2835 as used in the RaspberryPi > > Model 1. This has been corrected in FreeBSD (see r312292 and > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216104) and GCC (see > > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01679.html) and appears to > > have never been present in Clang. > > > > Unfortunately, it seems that various freeware still expects to find > > __ARM_ARCH_6ZK__, rather than the correct __ARM_ARCH_6KZ__. Within > > FreeBSD-13, there are references to __ARM_ARCH_6ZK__ (only) in: > > contrib/openmp/runtime/src/kmp_platform.h > > contrib/subversion/subversion/libsvn_subr/lz4/lz4.c > > crypto/openssl/crypto/arm_arch.h > > sys/arm/include/acle-compat.h > > sys/contrib/zstd/lib/legacy/zstd_v0?.c > > sys/contrib/zstd/lib/common/xxhash.c > > sys/contrib/zstd/lib/common/mem.h > > > > In most cases, the incorrect definition just leads to poor code (because > > the relevant model-specific optimisations aren't enabled) but some ports > > are fussier: I discovered the problem because ports/security/libressl > > won't build on my RPi since libressl refuses to build if it doesn't find > > an __ARM_ARCH_.* definition that it likes. > > > > Fixing FreeBSD base code is technically fairly easy. Fixing every port > > that potentially checks for __ARM_ARCH_6ZK__ is much harder (somewhat on > > a par with fixing the assumption that FreeBSD-1* is a.out, not ELF). I > > had a quick check through my ports distfiles and __ARM_ARCH_6ZK__ is > > referenced more often than I'd expect. > > > > The options for ports would seem to be: > > 1) Hack clang to export __ARM_ARCH_6ZK__ as well as __ARM_ARCH_6KZ__ > > 2) Expect every port maintainer to fix subtle misbehavour on the RPi1 > > by adding appropriate patches. > > 3) When building on ARM, run a sed script that fixes any occurrences > > of __ARM_ARCH_6ZK__. > > > > I'd prefer #1. Or a 1a that defines the bad one if the good one is defined > in some appropriate system header. It has become a defacto API... > > Warner When gcc fixed the problem, they added the correct spelling and left the incorrect one in place for the predefined symbol. They also made both spellings be accepted on the command line -march= arg. I think that's the only sensible thing for clang to do as well. A datapoint that supports the idea that the misspelled version is an API cast in stone for all time is that the acle-compat.h file distributed by ARM uses the original GCC misspelled version, and ARM has never updated that file to support both spellings; they seem to expect the bad spelling to be supported forever. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7e88e9e6280b81ae1327389fdd1f8298007df493.camel>