From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 292F93858424; Mon, 18 Oct 2021 21:10:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 292F93858424 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: Drq2S0ae4nT+55BMuWX+IdvAY44NXjVeOF4HjIx8bJSa+WCApjnyA+NPD2mzezyZZv7dAfjlDw vGFagZ093u3wA37wFZHhhbQNoNUM4omREn6QJOO2CJp6SHdNjIsq/MVjTp2HUynlybihuuIB24 rT4aQ6jESDTMJ1Mkg470kNc1vBn5pCqFjs9a86mGI8qZ6JZuIXm33aXm7cws3qjIWLnmLaUTfq 7erLvZGSwZTZsZ2kwB7dvCdEedBHy1+65IoPxU8xENc39LHMK9N2lX4WC4zBUSCGhrBSSP/Szw JFXlH8NfI/QB3XYtc1Vl+q8v X-IronPort-AV: E=Sophos;i="5.85,382,1624348800"; d="scan'208";a="67333137" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 18 Oct 2021 13:10:17 -0800 IronPort-SDR: H4H5vNIpA94iWPh2uRHgckT/h429ZWkM2XGCj4YzLiJjTZfa81uVZ3z2BAgqrlq3BXH8Gi7SnA 6nh3NGCXmL5qhgHBj7VOKjvY/vEA99+IjeEJal0ejd/6vqUh0X5mHG0ToKr1k7jZkM26aLH2o8 o3Z3rYWVCSJWO0nVfj5pXg4T41tMb2QKj6nM+KhGBpMljZpfacWgPt94WoqhVGBfCgjlcYb0SE 4GibMSO8+/eprKBrFRqNxPkriqgMyE9WfJEuMNtwCI3MuEBxmdW+SSnn5YhTlYxphx8Vmw6WFC jwQ= Date: Mon, 18 Oct 2021 21:10:11 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: =?UTF-8?Q?F=C4=81ng-ru=C3=AC_S=C3=B2ng?= CC: "H.J. Lu" , 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 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 21:10:20 -0000 On Mon, 18 Oct 2021, Fāng-ruì Sòng via Libc-alpha wrote: > I know. I have mentioned that the situation is not different from many > previous situations where a compatibility check may not catch > everything. That also applies to many changes to glibc functions. We use symbol versioning when adding new symbols, or when changing a symbol in a way incompatible with existing binaries making valid use of glibc APIs. We rarely use it when adding a new feature to an existing symbol (for example, a new flag for a function that takes a flags argument, or providing stricter guarantees about a return value that wasn't fully specified before), even though in fact binaries using the new feature would not work correctly when run with older glibc versions. I don't think a new ELF feature is that different from new features added to existing functions. -- Joseph S. Myers joseph@codesourcery.com