[PATCH] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_

[PATCH] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_

[Hui Li]

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

This is because some architectures such as LoongArch define the symbol
_PROCEDURE_LINKAGE_TABLE_ at the start of the .plt section. Add plt
symbol check for _PROCEDURE_LINKAGE_TABLE_ to improved the judgment of
plt symbol and to get correct target function address of STT_GNU_IFUNC.

```
loongson@bogon:~$ cat test.c
int main(int argc, char const *argv[])
{
  printf("hello world\n");
  return 0;
}
loongson@bogon:~$ gcc test.c -o test
loongson@bogon:~$ objdump -d test

test:     file format elf64-loongarch

Disassembly of section .plt:

0000000120004000 <_PROCEDURE_LINKAGE_TABLE_>:
   120004000:	8e 01 00 1c ad bd 11 00 cf 01 c0 28 ad 51 ff 02     ...........(.Q..
   120004010:	cc 01 c0 02 ad 05 45 00 8c 21 c0 28 e0 01 00 4c     ......E..!.(...L

0000000120004020 <__libc_start_main@plt>:
   120004020:	1c00018f 	pcaddu12i   	$t3, 12(0xc)
   120004024:	28ffc1ef 	ld.d        	$t3, $t3, -16(0xff0)
   120004028:	4c0001ed 	jirl        	$t1, $t3, 0
   12000402c:	03400000 	andi        	$zero, $zero, 0x0

0000000120004030 <abort@plt>:
   120004030:	1c00018f 	pcaddu12i   	$t3, 12(0xc)
   120004034:	28ffa1ef 	ld.d        	$t3, $t3, -24(0xfe8)
   120004038:	4c0001ed 	jirl        	$t1, $t3, 0
   12000403c:	03400000 	andi        	$zero, $zero, 0x0

0000000120004040 <puts@plt>:
   120004040:	1c00018f 	pcaddu12i   	$t3, 12(0xc)
   120004044:	28ff81ef 	ld.d        	$t3, $t3, -32(0xfe0)
   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

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)
     {
-- 
2.38.1

Re: [PATCH] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_

[Tom Tromey]

>>>>> Hui Li <lihui@loongson.cn> writes:

> This is because some architectures such as LoongArch define the symbol
> _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt section. Add plt
> symbol check for _PROCEDURE_LINKAGE_TABLE_ to improved the judgment of
> plt symbol and to get correct target function address of STT_GNU_IFUNC.

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?

Tom

Re: [PATCH] gdb/elfread.c: Add plt symbol check for _PROCEDURE_LINKAGE_TABLE_

[Hui Li]

On 2023/3/25 上午12:16, Tom Tromey wrote:
>>>>>> Hui Li <lihui@loongson.cn> writes:
> 
>> This is because some architectures such as LoongArch define the symbol
>> _PROCEDURE_LINKAGE_TABLE_ at the start of the .plt section. Add plt
>> symbol check for _PROCEDURE_LINKAGE_TABLE_ to improved the judgment of
>> plt symbol and to get correct target function address of STT_GNU_IFUNC.
> 
> 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?
> 
> Tom
> 

Thanks for your review.

This is a minor fix for one of the subfunction about ifunc.
The principle of ifunc and its implementation in gdb are not
explained in detail. So it's hard to understand how it relates
to the problem.

I change the commit message to explain this process in detail,
and send V2.
https://sourceware.org/pipermail/gdb-patches/2023-March/198303.html

Thanks.
Hui