From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 008363858C27; Mon, 18 Oct 2021 23:00:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 008363858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 0VHwUwMb5Eg3rPre22t28vzg+q1BzdQJrRDgLprh4r/Qt9LO+8ASsr1nIJLS7mWMVJgUHi7dgF r65SDlsnPxgU5fJtTmNPheiClt4XoqOJZ1xw0lXr7WpguoIDWxBGa8Gwp5ex6fBUnzq13W/pkc RvtS9Kv5yWaU8nG9u7AsH+Tc5p28WlSzz0fI619MBtwJhYidxJrALNXaLTbUBLNPm6VGoH8aJb lc27yrABTo2+f2yEpUZOm14cBHI5/oWkl5HfNEjqdSnPKrP24iuMCzoJnbMXk9taoOHyj1PdYI +lZR1gFxWfys3c8/YKO5wH+a X-IronPort-AV: E=Sophos;i="5.85,382,1624348800"; d="scan'208";a="67356017" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 18 Oct 2021 15:00:08 -0800 IronPort-SDR: VN/cdWon6kiWKBeMjZb15QXXZmFdayG8KBBzfrIC2BCaYbVwvMW7739Lnlyx2jursdKuFt+2Ge rAZkspuH/GC+QwaHnJPwVLnZCkfVgblBZDctIdpx7qvyeez+GN0UMdu5xHcDzY3Bz/mSBGHlU0 IHkQsa7oPVEdD2opOSWCSLvXB4MBaMB6rCtSRi1IUXQYwOV0py3CNAuInz+J55UyXK2Di/rDaZ kujkqh88Ll18B/q3MEOr5DLMMDrmzLWdFcKmScQzbSkxWdjr0hfGhWpW4bI8fAY9G6yS2nHgsh nPc= Date: Mon, 18 Oct 2021 23:00:03 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: GNU C Library , Binutils Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] In-Reply-To: Message-ID: References: <20211017005020.2645717-1-maskray@google.com> <20211018181530.yz62n64dgn2kd4oe@google.com> <20211018191902.vcf3u5s7h5losxyt@google.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 18 Oct 2021 23:00:11 -0000 On Mon, 18 Oct 2021, H.J. Lu via Libc-alpha wrote: > On Mon, Oct 18, 2021 at 3:30 PM Joseph Myers wrote: > > > > On Mon, 18 Oct 2021, H.J. Lu via Libc-alpha wrote: > > > > > If a binary requires a new glibc to run, running it with the old glibc will > > > lead to an ld.so diagnostic message. DT_RELR shouldn't be different. > > > > My point is that in many cases (for example, a binary using a new flag as > > an argument to a function taking a flags argument) it *won't* lead to an > > ld.so diagnostic message, just to the relevant function call misbehaving > > at runtime. > > Do you have such a testcase? It sounds like a glibc bug to me. We could take my recently submitted patch for printf %b and %B as an example of the sort of thing we haven't considered to need new symbol versions in the past. If someone builds a program using any of about 70 printf-like functions (three times as many on powerpc64le because of long double variants) with a %b or %B format, it won't work correctly with older glibc versions, but the symbol versions won't prevent it from running on older glibc versions. We haven't considered new printf/scanf/strftime/strfmon formats to need new symbol versions before (and if we did, there would be a lot of such versions in the printf case because there are a lot of printf-like functions). (The strtol-like and scanf-like functions will need new symbol versions for the binary input changes because they will also affect the handling of base 2 / base 0 input starting with 0b, i.e. change semantics of code that was already valid with previous glibc and standard versions. But there are fewer such functions.) -- Joseph S. Myers joseph@codesourcery.com