From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id D67823858C27; Mon, 18 Oct 2021 23:44:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D67823858C27 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: RLIIV/NZhTI3kUoeCHo4cjXFqzk5O70N2ycrOZrMVQYhn4LUqJdsAiMxVIri5KGS/VqgPFxD6U 6RXD57YTEt3QIcYUlGQapmggttpZmQyt926/2AKFTHICec2LOV2xhH0kTwS+jLf+wDqSYegtVl JWUTcboXXRazswR4mz9lt3vBgmDlf6/qhYQkKGda67LhR1P4NEmWBHQXkSsleqeEy4iD1AdTAO x43vOQrM5OEEx94tzfUGTYMwMZh91lKCzTcfqbCFUzDVY6J8ATy8+zxzCbd1d3r3nri13iYwE9 4v3Kxu5RQ7HOc8YcAc2vGfAd X-IronPort-AV: E=Sophos;i="5.85,382,1624348800"; d="scan'208";a="67202712" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 18 Oct 2021 15:44:56 -0800 IronPort-SDR: dqBJt9tXg5vnLn8RoguKsttgD3cjhbMTopmBJsfqzDM3e4ncPwmdfd27VbK1jFwA3vdKAN30Qv rLyQmnIv3cInF7GxPsSf79wD8Cae1Apy98cnBKZHS1Nh4Dz8jMtXOy6JrDbP4R74NtgmC6Isgo 8x229+PW3UUrzty7dOQ7Y6qcq+muoVTkQcfcXHrWYyZYdkiX5IoIvUbvEyGYQZNJphk05LPTRf NOaFaEJ1hWIjyMc4Z628/TFuNzLgALnM9FNgA5JpQgM/Eixw1S5ymQXCNKkXtKJj+ec8jGAzCR s/E= Date: Mon, 18 Oct 2021 23:44:49 +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-07.mgc.mentorg.com (139.181.222.7) 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:44:58 -0000 On Mon, 18 Oct 2021, H.J. Lu via Libc-alpha wrote: > Ideally when the new specifiers are used, it should require the new > glibc version. Is there a way to do it? I don't think there's any sensible way to do it. You'd need new symbol versions (aliased to the old ones, not actual separate entry points with different addresses) for all the 70 or so printf-like functions (twice that number when two long double variants are supported, three times that number when three long double variants are supported). That's not something we've done before for new printf/scanf/strftime/strfmon formats. The scanf changes will get new __isoc23_* entry points because of API differences with scanf %i (but someone could still e.g. use scanf %b when building for strict C11, and so get a binary using the old entry point with a new format that doesn't work with older glibc - there would only be the 32 / 44 / 56 new entry points, not new symbol versions for old entry points). -- Joseph S. Myers joseph@codesourcery.com