From patchwork Mon Mar 27 09:32:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hui Li X-Patchwork-Id: 66930 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C91B2385842D for ; Mon, 27 Mar 2023 09:33:08 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id C6FC33858D39 for ; Mon, 27 Mar 2023 09:32:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6FC33858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8BxEJW4YiFkh08SAA--.27924S3; Mon, 27 Mar 2023 17:32:41 +0800 (CST) Received: from localhost.localdomain (unknown [113.200.148.30]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Axlry2YiFkpxcOAA--.7160S2; Mon, 27 Mar 2023 17:32:39 +0800 (CST) From: Hui Li To: gdb-patches@sourceware.org Subject: [PATCH v2] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_ Date: Mon, 27 Mar 2023 17:32:33 +0800 Message-Id: <20230327093233.11423-1-lihui@loongson.cn> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-CM-TRANSID: AQAAf8Axlry2YiFkpxcOAA--.7160S2 X-CM-SenderInfo: 5olk3xo6or00hjvr0hdfq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxWryfZFWktrWfWw15Zr15XFb_yoWrur1Dpr WUtrW5CF4kX348Awn7Gr1rJr45Zr93A3WUCrW5Kr1SvrW5Xr17XrW0k3yYgFWfJrs5ZFyI v3ZrZr40vFn5AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU b7AYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x0EwIxGrwCFx2 IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v2 6r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67 AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IY s7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr 0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1CPfJUUUUU== X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_STOCKGEN, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" In the current code, when execute the following test on LoongArch: $ make check-gdb TESTS="gdb.base/gnu-ifunc.exp" === gdb Summary === # of expected passes 111 # of unexpected failures 62 According to IFUNC's working process [1]. first time the IFUNC function is called, the dynamic linker will not simply fill the .got.plt entry with the actual address of IFUNC symbol, it will call the IFUNC resolver function and take the return address, uses it as the sym-bound address and puts it in the .got.plt entry. Initial address in .got.plt entry is not a real function addresss. Depending on the compiler implementation, some different addresses will be filled in. Most architectures will use a.plt entry address to fill in the corresponding.got.plt entry. In gdb, elf_gnu_ifunc_resolve_addr() will be called to return a real IFUNC function addresss. first check to see if the real address for the IFUNC symbol has been resolved by the following function: elf_gnu_ifunc_resolve_name (const char *name, CORE_ADDR *addr_p) { if (elf_gnu_ifunc_resolve_by_cache (name, addr_p)) return true; if (elf_gnu_ifunc_resolve_by_got (name, addr_p)) return true; return false; } in elf_gnu_ifunc_resolve_by_got(), it gets the contents of the .got.plt entry and determines if the contents is the correct address by calling elf_gnu_ifunc_record_cache(). Based on the IFUNC working principle analysis above. the address filled in the.got.plt entry is not the actual target function address Initially, it would be a.plt entry address Corresponding symbol like *@plt. In this case, gdb just go back to execute the resolver function and puts the return address in the.got.plt entry. After that, gdb can get a real ifun address via got.plt entry. on LoongArch, Initially, each address filled in the.got.plt entries is the first plt entry address. some architectures such as LoongArch define the symbol _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt section. This symbol is the first plt entry, So gdb needs to check this symbol in elf_gnu_ifunc_record_cache(). on LoongArch got.plt and .plt as follow: $objdump -D gdb/testsuite/outputs/gdb.base/gnu-ifunc/gnu-ifunc-0-0-0 ... 0000000120010008 <.got.plt>: 120010008: ffffffff 0xffffffff 12001000c: ffffffff 0xffffffff ... 120010018: 20004000 ll.w $zero, $zero, 64(0x40) 12001001c: 00000001 0x00000001 120010020: 20004000 ll.w $zero, $zero, 64(0x40) 120010024: 00000001 0x00000001 120010028: 20004000 ll.w $zero, $zero, 64(0x40) 12001002c: 00000001 0x00000001 120010030: 20004000 ll.w $zero, $zero, 64(0x40) 120010034: 00000001 0x00000001 ... Disassembly of section .plt: 0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>: 120004000: 1c00018e pcaddu12i $t2, 12(0xc) 120004004: 0011bdad sub.d $t1, $t1, $t3 120004008: 28c021cf ld.d $t3, $t2, 8(0x8) 12000400c: 02ff51ad addi.d $t1, $t1, -44(0xfd4) 120004010: 02c021cc addi.d $t0, $t2, 8(0x8) 120004014: 004505ad srli.d $t1, $t1, 0x1 120004018: 28c0218c ld.d $t0, $t0, 8(0x8) 12000401c: 4c0001e0 jirl $zero, $t3, 0 0000000120004020 <__libc_start_main@plt>: 120004020: 1c00018f pcaddu12i $t3, 12(0xc) 120004024: 28ffe1ef ld.d $t3, $t3, -8(0xff8) 120004028: 4c0001ed jirl $t1, $t3, 0 12000402c: 03400000 andi $zero, $zero, 0x0 0000000120004030 : 120004030: 1c00018f pcaddu12i $t3, 12(0xc) 120004034: 28ffc1ef ld.d $t3, $t3, -16(0xff0) 120004038: 4c0001ed jirl $t1, $t3, 0 12000403c: 03400000 andi $zero, $zero, 0x0 0000000120004040 : 120004040: 1c00018f pcaddu12i $t3, 12(0xc) 120004044: 28ffa1ef ld.d $t3, $t3, -24(0xfe8) 120004048: 4c0001ed jirl $t1, $t3, 0 12000404c: 03400000 andi $zero, $zero, 0x0 ... With this patch: $make check-gdb TESTS="gdb.base/gnu-ifunc.exp" === gdb Summary === #of expected passes 173 [1] https://sourceware.org/glibc/wiki/GNU_IFUNC Signed-off-by: Hui Li --- gdb/elfread.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gdb/elfread.c b/gdb/elfread.c index b414da9ed21..1e606783c33 100644 --- a/gdb/elfread.c +++ b/gdb/elfread.c @@ -722,6 +722,9 @@ elf_gnu_ifunc_record_cache (const char *name, CORE_ADDR addr) if (len > 4 && strcmp (target_name + len - 4, "@plt") == 0) return 0; + if (strcmp (target_name, "_PROCEDURE_LINKAGE_TABLE_") == 0) + return 0; + htab = elf_objfile_gnu_ifunc_cache_data.get (objfile); if (htab == NULL) {