From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.esperi.org.uk (icebox.esperi.org.uk [81.187.191.129]) by sourceware.org (Postfix) with ESMTP id 237BD3971825 for ; Mon, 8 Feb 2021 13:35:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 237BD3971825 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=esperi.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=nix@esperi.org.uk Received: from loom (nix@sidle.srvr.nix [192.168.14.8]) by mail.esperi.org.uk (8.16.1/8.16.1) with ESMTP id 118DZQse019028; Mon, 8 Feb 2021 13:35:26 GMT From: Nix To: "Andreas K. =?utf-8?Q?H=C3=BCttel?= via Libc-alpha" Cc: Florian Weimer , "Andreas K. =?utf-8?Q?H=C3=BCttel?=" , Joseph Myers Subject: Re: [PATCH v2] x86: Require full ISA support for x86-64 level marker [BZ #27318] References: <20210202215112.1002416-1-hjl.tools@gmail.com> <87k0rom825.fsf@oldenburg.str.redhat.com> <6586609.jJDZkT8p0M@farino> Emacs: an inspiring example of form following function... to Hell. Date: Mon, 08 Feb 2021 13:35:29 +0000 In-Reply-To: <6586609.jJDZkT8p0M@farino> ("Andreas K. =?utf-8?Q?H=C3=BCtte?= =?utf-8?Q?l?= via Libc-alpha"'s message of "Fri, 05 Feb 2021 00:55:34 +0200") Message-ID: <87zh0e3cny.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-DCC-wuwien-Metrics: loom 1290; Body=4 Fuz1=4 Fuz2=4 X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, LIKELY_SPAM_BODY, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 13:35:48 -0000 On 4 Feb 2021, Andreas K. Hüttel via Libc-alpha outgrape: > Also, is Sandy Bridge the only case where this happens? Definitely not. Thank goodness I spotted this thread: I just nearly wrecked my (32-bit) AMD Geode firewall (built with -march=geode) installing 2.33, because it is showing up with this totally wrong ABI-needed stamp: Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x0000000c NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA needed: x86-64-v2 merely because it is built on a Broadwell CPU (Geodes are a bit too slow to build glibc these days, and also this Geode has no compiler installed). (My GCC is GCC 10.2 built with -march=native, but obviously the -march=geode used at glibc compilation time usually overrides this perfectly well and glibc works fine.) It seems to me that this brings back the same problem we used to have with the --enable-kernel option, where specifying a minimum kernel version that was too high would lead to all binaries failing to execute, only worse: if you *do* upgrade and not keep the old shared libraries around to sln to (and don't have a statically-linked busybox shell or something to recover), you can't recover by merely starting a suitable kernel: you have to *physically upgrade the processor*, which is probably impossible. (Or boot off an emergency rescue disk or something, and recover from there). This despite the fact that a 32-bit x86 glibc is not going to be using any of the (by definition x86-64-specific) facilities that the ISA level is checking for, so it's not even preventing execution for a good reason! (We don't even use SSE math on x86-32, do we?) Worse yet, because this is looking at the CPU ID, tests in a compilation container are going to pass: even tests in a virtual machine will probably pass, only to fail disastrously as soon as you install on the real hardware.