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

[Tiezhu Yang <yangtiezhu@loongson.cn>]

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