From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 508B01F953 for ; Thu, 28 Oct 2021 14:22:49 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 333523857C6B for ; Thu, 28 Oct 2021 14:22:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 333523857C6B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1635430968; bh=x/3Sk0VIfbJmRyoq7Fy3txJyZPbLuU7WWL3OnDADQEA=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=bY4EiAV4gOM7ZVj3q4UvBJPbz5mYaS5m2ltg/EMv59Eiz2u1AuFnxfdAu+5/dXFrC oPM06J7xze7qXHFKkVvcnABSl5ZT8Ial5RMFbcq2M7ZO3n18CWeIJd5OXD2vq7a59A DYsbAJbRot7HKrSRfshEU0Bp3C9gsGT6ZkzoVZWE= Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id E2ACE3857817; Thu, 28 Oct 2021 14:21:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2ACE3857817 Received: by mail-pj1-x102d.google.com with SMTP id om14so4801553pjb.5; Thu, 28 Oct 2021 07:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x/3Sk0VIfbJmRyoq7Fy3txJyZPbLuU7WWL3OnDADQEA=; b=aJfKqzfZy7qUMlfZGQL+OTAji5qb+pqx+dAtpF6TLBPS9s2ltdkWoLXpWyu8daT0fY Lxvl9sE1ndmEjnwI59UXnl92yIjwRNvXo1+TB3DOEO1S1JH0HxUfiIdp8LRgm1tDotr/ gjyQh83HRF3npFzTU/U11tUVTk8ftMZRPUIgUgXCVqKKIpHZMnId/BDGq83kmlqUE9rp ZlKsNsZ8qX+8VdiIwBedCKB7WxFFY+Jicku5B/L00lPW4cod/ui0ZsiNTwIu/yowLB0R S+c3GChgiCcgItlgTmoOq3hTAwLT7tqQOC88XDhfX/HEWmYzAWuz51eBytyt/WgZRgPD Bwqg== X-Gm-Message-State: AOAM531w7taiM3LxAwnrMEzEjczPJ6OT511YFIeaj+lmfKGIi+OTnMNl eWEhKorK5CNPKKNFIa0E4s0ngRj3dMa6XihJvJkZgnmu0iM= X-Google-Smtp-Source: ABdhPJzpRly/8NbUMehAN7vT7PGoeHJHSehCGJCzi/8xCe1Mir56b0TBff4JEGHylrUBgAIrGbjS0y0IauVo73F5lFs= X-Received: by 2002:a17:902:cec7:b0:140:4a11:799f with SMTP id d7-20020a170902cec700b001404a11799fmr4215460plg.27.1635430868072; Thu, 28 Oct 2021 07:21:08 -0700 (PDT) MIME-Version: 1.0 References: <87zgqvq03g.fsf@oldenburg.str.redhat.com> <87v91hljth.fsf@oldenburg.str.redhat.com> <87k0hxkzrz.fsf@oldenburg.str.redhat.com> In-Reply-To: Date: Thu, 28 Oct 2021 07:20:32 -0700 Message-ID: Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED To: Florian Weimer Content-Type: text/plain; charset="UTF-8" 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: "H.J. Lu via Libc-alpha" , Binutils Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, Oct 28, 2021 at 7:17 AM H.J. Lu wrote: > > On Thu, Oct 28, 2021 at 7:08 AM Florian Weimer wrote: > > > > * H. J. Lu: > > > > > I am not sure if I am following your concerns. We have an ELF feature, > > > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > > > will crash with the older glibcs. And you DON'T want such a binary with > > > a dependency on the required glibc version. Can you tell me why? > > > > Historically, such features have not been tied to a glibc version. CET, > > DT_AUDIT, AArch64 variant PCS support, nearly arbitrary calling > > convention support on x86-64 all are not really version-specific (they > > have been backported to varying degrees), and those involve dynamic > > linker features. > > > > In contrast, if DT_RELR support is indicated by a GLIBC_2.35 version > > dependency, it is necessary to backport all of the GLIBC_2.35 symbol set > > as part of the DT_RELR backport. This means such backports are usually > > not feasible. > > So you would like to backport DT_RELR. > > > >> >> The problem that linkers and loaders ignore unknown types should be > > >> >> tackled in a different way, e.g. by flagging critical types in some way. > > >> >> See: > > >> >> > > >> >> Critical program headers and dynamic tags > > >> >> > > >> >> > > >> > > > >> > This won't help the existing ld.so binaries which this proposal > > >> > is addressing. > > >> > > >> We need to increase the ABI version once, to signal the requirement for > > >> critical tags checking. > > >> > > > > > > Which ABI version? .note.ABI-tag or EI_ABIVERSION? A binary linked > > > against glibc 2.40 without DT_RELR can run with glibc 2.34. But a binary > > > linked against glibc 2.30 with DT_RELR won't run with glibc 2.34 at all. > > > Increasing the ABI version doesn't solve the DT_RELR issue. > > > > The way EI_ABIVERSION works is that the link editor produces the minimum > > version needed by the features in the binary. > > > > So if the link editor DT_RELR, it would produce a DT_CRITICAL_DT tag for > > DT_RELR and set EI_ABIVERSION for critical DT tag support. Similar for > > other critical DT Tags. If no critical DT tags are used, an earlier > > EI_ABIVERSION can be used. > > > > There is no DT_CRITICAL_DT support in the older glibcs. The only option > is EI_ABIVERSION and I don't think we need DT_CRITICAL_DT. We update > EI_ABIVERSION whenever there is a new feature added. I think it is one > missing piece in the original DT_RELR proposal. > How do we deal with Somes binaries compiled with the new language features, like C2X printf specifiers, only generate correct results with the new glibc binary. Since we don't add new glibc versions to the printf function family, they generate incorrect results at run-time with the older glibc binaries. -- H.J.