From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.hgst.iphmx.com (esa3.hgst.iphmx.com [216.71.153.141]) by sourceware.org (Postfix) with ESMTPS id 2763B3851C0D for ; Wed, 1 Jul 2020 00:45:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2763B3851C0D IronPort-SDR: 3dIm+YCpw+RZk/atvzF756ENplvAf4/BBSp8HFwBQLMC8J0E6R+Xv+AaGAQVCf9QiQ9tj9eTCe f5vgoL6YOI81uG2AGCQQqJQnaRM4dTOwG1/rJi5mx0m/lTLwFgQMKCKcY+jnstf4z0etA/Gs1b 7SPEUpWcWU/+6xs1Z2fxFzT0yipIFDD3KtUjJbiFfHGFeYjWo3s8B0bUqmVtSbr0N4vjZGvQQO OD/u3DcnaFBpm1NiY863Aghgw+IarNL+CgZIaPmvSV9nCBeekFsi6/RIGeOInSJ7LPo7qah50K Mlk= X-IronPort-AV: E=Sophos;i="5.75,298,1589212800"; d="scan'208";a="145650669" Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 01 Jul 2020 08:45:19 +0800 IronPort-SDR: qf2L4LVkWckb3R7zS7Jyp2pqVwHux9A6+ZY9bxAO1AsxKTGuI5n/t1w4UiyWPWrztIHB5CB3KH KjJ02cd2o5AEhHsF0ovRa8V6d5lkTA4S0= Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2020 17:34:09 -0700 IronPort-SDR: EQEfHhHI93YhwpMlr1V7pWeSelw6euAGaeLR4zntVi1Vo7D+YhmpxIWtIr76RmNHnJ/6EIlrvV 9pXxj5TTIy4A== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2020 17:45:17 -0700 Date: Wed, 1 Jul 2020 01:45:12 +0100 (BST) From: "Maciej W. Rozycki" To: Jim Wilson cc: Florian Weimer , Alistair Francis , Alistair Francis via Libc-alpha , Andreas Schwab Subject: Re: [PATCH] Allow memset local PLT reference for RISC-V. In-Reply-To: Message-ID: References: <20200622211034.659739-1-alistair.francis@wdc.com> <87zh8u8d17.fsf@igel.home> <87o8p21bjh.fsf@oldenburg2.str.redhat.com> <87366dx35x.fsf@oldenburg2.str.redhat.com> <87sgedvnq3.fsf@oldenburg2.str.redhat.com> <87o8p1vnb9.fsf@oldenburg2.str.redhat.com> <87ftadvmnv.fsf@oldenburg2.str.redhat.com> <87r1txyfew.fsf@igel.home> <87a70lvm48.fsf@oldenburg2.str.redhat.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 01 Jul 2020 00:45:20 -0000 On Mon, 29 Jun 2020, Jim Wilson wrote: > Anyways, if you want to know where the PLT call is coming from, you > can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt > call. If a PLT entry has been created, then the linker must have considered the symbol referred preemptible, whether legitimately or not. Rather than scratching one's head I would suggest running the relevant LD invocation under GDB to find out what really happens there, which may be as easy as setting a breakpoint on `riscv_elf_finish_dynamic_symbol' with the right condition on the hash entry so as to stop on `memset' only, and then working backwards with a watchpoint (on a host system that does not use ASLR) to find out what sets `h->plt.offset'. There'll be the answer. HTH, Maciej