From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 403C53858C27; Mon, 18 Oct 2021 22:30:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 403C53858C27 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: IqJfNrqgjvO0fTkuK1U4N1bKtxP0Dk9iAVsMeulYfukqRVlb99BlpC1tohdFHJX9MnVGm57z6b k4vY+4Ms7DGCaRx0MuPJ2PA9DAnGXHF89HsWz/Ezh1HdD3N5ZPjF/DGffUasAPuRqKOGfQs3xI HshU7efNGdHT92JQOhLaGYch8H5ZMTZsvWWMk/mMtU/POJJrkUpakKvtlVrOhAPJVGy/xDReHk Q2k9Zo5xNUi/DXBMbYpyq+28K14obQ7nvQ57E6I7uFZ6Vdk2oq2IE9f092jzcMoMiiwOOUvU6F DqF7DXh4S5O1VQzl8b4UM52f X-IronPort-AV: E=Sophos;i="5.85,382,1624348800"; d="scan'208";a="69805695" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 18 Oct 2021 14:30:23 -0800 IronPort-SDR: gKGrJghXt+4qrYwNTs8ZQTtOWKfwqjfl62nM7nxHBj04RA6F85vh4icpMYnvJt46q4H9JPZAKl ZDfmj1ZQyDEDl0f3Rn0P2jxXHAOAtMYtFXMhW1UXmJScwYQsQxDxNuQWXafKUqi5vxFTnTricq 5aLcwglkT9jQ/K9pu80utLOQAJqsX1dhp/cckEUhAVNF58QhROvuRpQk5gHRn2a0roKSCeDenZ UGZsKWEgRNRpK60TKC2xeSkjwS097pY5EwkFJMjP5TjrJPmCGUNvC5lwNrr7421MxTqsMnAvPZ iTc= Date: Mon, 18 Oct 2021 22:30:18 +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-05.mgc.mentorg.com (139.181.222.5) 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 22:30:25 -0000 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. -- Joseph S. Myers joseph@codesourcery.com