Message ID | 20230410123030.25326-1-lihui@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> 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 EC0843858284 for <patchwork@sourceware.org>; Mon, 10 Apr 2023 12:30:54 +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 3BCE43858C52 for <gdb-patches@sourceware.org>; Mon, 10 Apr 2023 12:30:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3BCE43858C52 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 _____8AxrtpsATRkLhoZAA--.27162S3; Mon, 10 Apr 2023 20:30:38 +0800 (CST) Received: from localhost.localdomain (unknown [113.200.148.30]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxLuRrATRkrYkcAA--.65138S2; Mon, 10 Apr 2023 20:30:35 +0800 (CST) From: Hui Li <lihui@loongson.cn> To: gdb-patches@sourceware.org Subject: [PATCH v2 RESEND] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_ Date: Mon, 10 Apr 2023 20:30:30 +0800 Message-Id: <20230410123030.25326-1-lihui@loongson.cn> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8CxLuRrATRkrYkcAA--.65138S2 X-CM-SenderInfo: 5olk3xo6or00hjvr0hdfq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxWryfZFWktrWfAr1rZrWxXrb_yoWrur4Dpr WUtrW5CF4kX348Awn7Gr1rJr45Zrn3A3WUCrW5Kr1SvrW5Xr17XrW0k3yYgFWrArs5ZFyI v3ZrZr40yFn5AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU b7xYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AI xVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1l5I8CrVACY4xI64 kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm 72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07UE-erUUUUU= X-Spam-Status: No, score=-10.6 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 <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[v2,RESEND] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_
|
|
Commit Message
Hui Li
April 10, 2023, 12:30 p.m. UTC
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 section 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 <abort@plt>:
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 <gnu_ifunc@plt>:
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 <lihui@loongson.cn>
---
gdb/elfread.c | 3 +++
1 file changed, 3 insertions(+)
Comments
Are you OK with this change? Any comments will be much appreciated. https://sourceware.org/pipermail/gdb-patches/2023-April/198731.html Thanks, Hui On 2023/4/10 下午8:30, Hui Li wrote: > 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 section 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 <abort@plt>: > 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 <gnu_ifunc@plt>: > 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 <lihui@loongson.cn> > --- > 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) > { >
On 04/10/2023 08:30 PM, Hui Li wrote: > 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 section 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 <abort@plt>: > 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 <gnu_ifunc@plt>: > 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 <lihui@loongson.cn> > --- > 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) > { > Hi, I noticed the following review comments by Tom Tromey [1] on Mar 24: It would be helpful to know how precisely things go wrong. The patch itself seems reasonable enough -- hacky maybe but not out of the ordinary way -- but I don't understand how it relates to the problem. Like, why does ignoring this symbol here affect the results? Are you OK for this v2 patch with the updated commit message resent on Apr 10 [2]? If no more comments, let me push this patch next week. [1] https://sourceware.org/pipermail/gdb-patches/2023-March/198285.html [2] https://sourceware.org/pipermail/gdb-patches/2023-April/198731.html Thanks, Tiezhu
On 5/11/23 19:35, Tiezhu Yang wrote: > > > On 04/10/2023 08:30 PM, Hui Li wrote: >> 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 >> ... >> 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 <lihui@loongson.cn> >> --- >> 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) >> { >> > > Hi, > > I noticed the following review comments by Tom Tromey [1] on Mar 24: > > It would be helpful to know how precisely things go wrong. > The patch itself seems reasonable enough -- hacky maybe but not out of > the ordinary way -- but I don't understand how it relates to the > problem. > Like, why does ignoring this symbol here affect the results? > > Are you OK for this v2 patch with the updated commit message resent on > Apr 10 [2]? If no more comments, let me push this patch next week. > > [1] https://sourceware.org/pipermail/gdb-patches/2023-March/198285.html > [2] https://sourceware.org/pipermail/gdb-patches/2023-April/198731.html > This patch is mainly related with LoongArch and no side effects on the other archs, pushed. Thanks, Tiezhu
>>>>> Tiezhu Yang <yangtiezhu@loongson.cn> writes: > This patch is mainly related with LoongArch and no side effects > on the other archs, pushed. Please don't do this in the future. It's not ok to touch generic code like this under the aegis of supporting some random port. Tom
On 05/19/2023 02:01 AM, Tom Tromey wrote: >>>>>> Tiezhu Yang <yangtiezhu@loongson.cn> writes: > >> This patch is mainly related with LoongArch and no side effects >> on the other archs, pushed. > > Please don't do this in the future. It's not ok to touch generic code > like this under the aegis of supporting some random port. > > Tom > OK, sorry for that. For generic code, Reviewed-By or Approved-By is necessary before pushing, I will be careful and wait more time to receive the tags, thank you. Thanks, Tiezhu
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) {