From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id DD43B386EC49 for ; Mon, 1 Mar 2021 16:06:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD43B386EC49 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-413-sfHJnZNwMsCk1hxi9wxYog-1; Mon, 01 Mar 2021 11:06:25 -0500 X-MC-Unique: sfHJnZNwMsCk1hxi9wxYog-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4920B107ACE3; Mon, 1 Mar 2021 16:06:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-131.ams2.redhat.com [10.36.113.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4AE655D6CF; Mon, 1 Mar 2021 16:06:22 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Cc: "H.J. Lu" , Joseph Myers Subject: Re: [PATCH v3] x86: Disable x86-64 level marker [BZ #27318] References: <20210202215112.1002416-1-hjl.tools@gmail.com> <87k0rom825.fsf@oldenburg.str.redhat.com> <6586609.jJDZkT8p0M@farino> <87k0rk8968.fsf@oldenburg.str.redhat.com> <87pn1a1tvb.fsf@oldenburg.str.redhat.com> <871rd875cp.fsf@oldenburg.str.redhat.com> <87im6k5hyn.fsf@oldenburg.str.redhat.com> Date: Mon, 01 Mar 2021 17:07:18 +0100 In-Reply-To: <87im6k5hyn.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Mon, 22 Feb 2021 14:51:12 +0100") Message-ID: <878s76eu2x.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.2 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, 01 Mar 2021 16:06:36 -0000 * Florian Weimer: > * H. J. Lu via Libc-alpha: > >> On Mon, Feb 22, 2021 at 2:40 AM Florian Weimer wrote: >>> I think this will produce an #error for if there is a lone -mavx in >>> addition to x86-64-v2 coverage in the compiler. The first block would >>> define ISA_V2, but the second block produces the error. I assume that >>> causes inclusion of the build note to be skipped. >> >> Correct. > > Okay, that explains why the checks are the way they are. Thanks. > >>> Is this really helpful? If glibc was built to run with on x86-64-v2 >>> CPUs with some extra, wouldn't it still make sense to perform the >>> x86-64-v2 diagnostic upon startup? >> >> Since libc.so now contains x86-64-v2 + extra, we can't mark it as >> x86-64-v2 since it may UD on x86-64-v2 machines. Or we can >> change the meaning of the ISA level marker from "this shared library >> REQUIRES ONLY x86-64-v2 to run" to "this shared library WON'T >> run without x86-64-v2". > > I think the loader check is worthwhile to add because otherwise people > will end up with half-working systems. In my experience, this can lead > to lots of bug reports because people assume that if only some things > are crashing, it must be a distribution bug. So the loader check is > quite valuable for documenting an baseline increase. > > I also think that the ELF markers are valuable if they specify the exact > ABI level to which the object has been built. But I do think we need > GCC and perhaps binutils support for generating them because otherwise, > new GCC features may silently build glibc with the wrong ABI level. For > example, with this patch and building on GCC 10 with > -march=icelake-server, it seems like I still get a property note: > > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: > > But -march=icelake-server is a superset of x86-64-v4, so that's not > correct, I think. glibc can't know a bout all these extra features, so > the generated note will always be misleading. A note produced elsewhere > in the toolchain would not have this problem. > > But we could still check for all the preprocessor macros we know that > should constitute x86-64-v2 &c, and error out in the dynamic loader if > there isn't support for them in the current process. Any further comments here? This bug keeps hitting more and more people. I think we should do the following: (a) disable the build note generation in glibc, (b) backport --list-diagnostics or something similar. The second part will hopefully help with analyzing failures due to CPU support mismatches. Thanks, Florian