RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

Aditya Kamath1 via Gdb-patches
2023-04-17T13:17:04Z

[-- Attachment #1: Type: text/plain, Size: 19064 bytes --]

Hi Tom, Ulrich and community,

Greetings. Please find attached a temporary patch. See { 0001-Fix-PC-read-in-psymtab-but-not-in-symtab-warning-for.patch}. Thank you Tom and Ulrich for your guidance so far.

Sorry for the previous email. I did not answer Tom’s query on Stabs. Resending the email again with the answer for the same.

Kindly note this is just a temporary patch. I want a review to this.

>The warning you are seeing means that the partial and full symbol
>readers disagree. This is a bug somewhere.
>Maybe the fix is to ensure a symbol is made in the full reader. It's
>also possible that the fix is to not make a partial symbol.
>Finding the issue isn't always very easy, but basically what you want to
>do is inspect the point at which the relevant partial symbol is made;
>then expand the CU; and finally see why the full reader doesn't make a
>corresponding symbol.
>TBH all of this stuff is a design flaw. In the DWARF reader I hope to
>unify the paths so that this kind of mismatch is impossible.

You are correct here Tom. I agree with you. Thank you for this.

So investigating further, I realised this psymtab::add_psymbol is the place where this partial symbol is made. But before that in xcoffread.c we create it {In the lines as shown in the patch in xcoffread.c}.

What I realised is the address that is being passed as GLOBALS looks bogus in the xcoffread.c file. I did not find it in object dump. The core address for which the psymtab entries made are 0 ,1a0, 0 and 8 for the below code.. These are not correct core addresses at all. I was surprised as to where it came from at first place.

bash-5.1$ cat ~/gdb_tests/simple_test.c
#include <stdio.h>
int global_variable = 2;
int main(){
int local_variable = 1;
printf ("Simple print statement \n");
printf ("Hello Bengaluru \n");
return 0;
}

Seeing the comments around the same place in xcoffread.c file at the hunk lines of this patch , it looks like someone already knew these addresses are incorrect in the past. And even in my investigation I figured out that these psymbols are incorrect. Hence when function shared library addresses are looked up in psymtab GDB finds the nearest best false pysmtab symbol and returns it. Which it should not do.

>Maybe the fix is to ensure a symbol is made in the full reader. It's
>also possible that the fix is to not make a partial symbol.

As per your guidance, I tried commenting out the psymtab entries here and ran all the GDB base testsuite test cases. The numbers remain unchanged. Passes = 29059 and Failures = 2227

So I guess it is better we remove this. I would like to know yours and Ulrich’s or any community members comments on it. But yeah, the root cause is the this. And you can see below those warnings now disappear as ps or psymtab symbol will be NULL when GDB tries to find printf () address which is already there is symtab. See disassemble and info symbol output also..

Output of GDB in AIX after this patch:-
./gdb ~/gdb_tests/simple_test
GNU gdb (GDB) 14.0.50.20230327-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/aditya/gdb_tests/simple_test...
(gdb) b main
Breakpoint 1 at 0x1000052c: file /home/aditya/gdb_tests/simple_test.c, line 4.
(gdb) r
Starting program: /home/aditya/gdb_tests/simple_test
Breakpoint 1, main () at /home/aditya/gdb_tests/simple_test.c:4
4 int local_variable = 1;
(gdb) n
5 printf ("Simple print statement \n");
(gdb)
Simple print statement
6 printf ("Hello Bengaluru \n");
(gdb)
Hello Bengaluru
7 return 0;
(gdb)
8 }
----------------------------------------
(gdb)

Breakpoint 1, main () at /home/aditya/gdb_tests/simple_test.c:4
4 int local_variable = 1;
(gdb) disassemble
Dump of assembler code for function main:
0x10000518 <+0>: mflr r0
0x1000051c <+4>: stw r0,8(r1)
0x10000520 <+8>: stw r31,-4(r1)
0x10000524 <+12>: stwu r1,-96(r1)
0x10000528 <+16>: mr r31,r1
=> 0x1000052c <+20>: li r9,1
0x10000530 <+24>: stw r9,56(r31)
0x10000534 <+28>: lwz r3,64(r2)
0x10000538 <+32>: bl 0x100005a8 <puts>
0x1000053c <+36>: lwz r2,20(r1)
0x10000540 <+40>: lwz r3,72(r2)
0x10000544 <+44>: bl 0x100005a8 <puts>
0x10000548 <+48>: lwz r2,20(r1)
0x1000054c <+52>: li r9,0
0x10000550 <+56>: mr r3,r9
0x10000554 <+60>: addi r1,r31,96
0x10000558 <+64>: lwz r0,8(r1)
0x1000055c <+68>: mtlr r0
0x10000560 <+72>: lwz r31,-4(r1)
0x10000564 <+76>: blr
0x10000568 <+80>: .long 0x0
0x1000056c <+84>: .long 0x2061
0x10000570 <+88>: lwz r0,1(r1)
0x10000574 <+92>: .long 0x50
0x10000578 <+96>: .long 0x46d61
0x1000057c <+100>: xori r14,r11,7936
End of assembler dump.
(gdb) info symbol 0x100005a8
puts in section .text of /home/aditya/gdb_tests/simple_test
(gdb) info address printf
Symbol "printf" is at 0xd0133760 in a file compiled without debugging.
(gdb)

So in linux when I turn on debug symfile and while it is about to execute printf I see
qf->find_pc_sect_compunit_symtab (simple_test, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (ld64.so.2, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (system-supplied DSO at 0x7ffff7f80000, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libc.so.6, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL

So I am thinking that find_pc_sect_compunit_symtab () must return NULL. In AIX as well it is returning NULL after applying current patch.

qf->find_pc_sect_compunit_symtab (libc.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (simple_test, 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libcrypt.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libc.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (simple_test, 0x1104a3b70, 0x1000053c, 0x0, 0)
qf->find_pc_sect_compunit_symtab (...) = /home/aditya/gdb_tests/simple_test.c

So I think at least we are in the right direction. Let me know what you think of this and I will proceed according to the guidance received.

Awaiting a reply.

>Actually I'm curious how important stabs are to your organization. I
>would like to deprecate stabs in gdb 14 and remove them entirely in gdb
>15. However, they are still required for AIX, I suppose we'd keep the
>code around as long as you need.

So I have taken this up with my seniors.. They are still required.. Kindly do not depreciate.. As soon as any decision is made to not use stabs and I receive an information on the same, I will communicate it to the GDB community, you and Ulrich that we can depreciate.. But we need stabs as of now..

Have a nice day ahead.

Thanks and regards,
Aditya.

From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Date: Monday, 17 April 2023 at 6:38 PM
To: Tom Tromey <tom@tromey.com>, Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom Tromey <tom@tromey.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>, Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>, simon.marchi@efficios.com <simon.marchi@efficios.com>
Subject: Re: [EXTERNAL] Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning
Hi Tom, Ulrich and community,

Greetings. Please find attached a temporary patch. See { 0001-Fix-PC-read-in-psymtab-but-not-in-symtab-warning-for.patch}. Thank you Tom and Ulrich for your guidance so far.

Kindly note this is just a temporary patch. I want a review to this.

>The warning you are seeing means that the partial and full symbol
>readers disagree. This is a bug somewhere.
>Maybe the fix is to ensure a symbol is made in the full reader. It's
>also possible that the fix is to not make a partial symbol.
>Finding the issue isn't always very easy, but basically what you want to
>do is inspect the point at which the relevant partial symbol is made;
>then expand the CU; and finally see why the full reader doesn't make a
>corresponding symbol.
>TBH all of this stuff is a design flaw. In the DWARF reader I hope to
>unify the paths so that this kind of mismatch is impossible.

You are correct here Tom. I agree with you. Thank you for this.

So investigating further, I realised this psymtab::add_psymbol is the place where this partial symbol is made. But before that in xcoffread.c we create it {In the lines as shown in the patch in xcoffread.c}.

What I realised is the address that is being passed as GLOBALS looks bogus in the xcoffread.c file. I did not find it in object dump. The core address for which the psymtab entries made are 0 ,1a0, 0 and 8 for the below code.. These are not correct core addresses at all. I was surprised as to where it came from at first place.

bash-5.1$ cat ~/gdb_tests/simple_test.c
#include <stdio.h>
int global_variable = 2;
int main(){
int local_variable = 1;
printf ("Simple print statement \n");
printf ("Hello Bengaluru \n");
return 0;
}

Seeing the comments around the same place in xcoffread.c file at the hunk lines of this patch , it looks like someone already knew these addresses are incorrect in the past. And even in my investigation I figured out that these psymbols are incorrect. Hence when function shared library addresses are looked up in psymtab GDB finds the nearest best false pysmtab symbol and returns it. Which it should not do.

>Maybe the fix is to ensure a symbol is made in the full reader. It's
>also possible that the fix is to not make a partial symbol.

As per your guidance, I tried commenting out the psymtab entries here and ran all the GDB base testsuite test cases. The numbers remain unchanged. Passes = 29059 and Failures = 2227

So I guess it is better we remove this. I would like to know yours and Ulrich’s or any community members comments on it. But yeah, the root cause is the this. And you can see below those warnings now disappear as ps or psymtab symbol will be NULL when GDB tries to find printf () address which is already there is symtab. See disassemble and info symbol output also..

Output of GDB in AIX after this patch:-
./gdb ~/gdb_tests/simple_test
GNU gdb (GDB) 14.0.50.20230327-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/aditya/gdb_tests/simple_test...
(gdb) b main
Breakpoint 1 at 0x1000052c: file /home/aditya/gdb_tests/simple_test.c, line 4.
(gdb) r
Starting program: /home/aditya/gdb_tests/simple_test
Breakpoint 1, main () at /home/aditya/gdb_tests/simple_test.c:4
4 int local_variable = 1;
(gdb) n
5 printf ("Simple print statement \n");
(gdb)
Simple print statement
6 printf ("Hello Bengaluru \n");
(gdb)
Hello Bengaluru
7 return 0;
(gdb)
8 }
----------------------------------------
(gdb)

Breakpoint 1, main () at /home/aditya/gdb_tests/simple_test.c:4
4 int local_variable = 1;
(gdb) disassemble
Dump of assembler code for function main:
0x10000518 <+0>: mflr r0
0x1000051c <+4>: stw r0,8(r1)
0x10000520 <+8>: stw r31,-4(r1)
0x10000524 <+12>: stwu r1,-96(r1)
0x10000528 <+16>: mr r31,r1
=> 0x1000052c <+20>: li r9,1
0x10000530 <+24>: stw r9,56(r31)
0x10000534 <+28>: lwz r3,64(r2)
0x10000538 <+32>: bl 0x100005a8 <puts>
0x1000053c <+36>: lwz r2,20(r1)
0x10000540 <+40>: lwz r3,72(r2)
0x10000544 <+44>: bl 0x100005a8 <puts>
0x10000548 <+48>: lwz r2,20(r1)
0x1000054c <+52>: li r9,0
0x10000550 <+56>: mr r3,r9
0x10000554 <+60>: addi r1,r31,96
0x10000558 <+64>: lwz r0,8(r1)
0x1000055c <+68>: mtlr r0
0x10000560 <+72>: lwz r31,-4(r1)
0x10000564 <+76>: blr
0x10000568 <+80>: .long 0x0
0x1000056c <+84>: .long 0x2061
0x10000570 <+88>: lwz r0,1(r1)
0x10000574 <+92>: .long 0x50
0x10000578 <+96>: .long 0x46d61
0x1000057c <+100>: xori r14,r11,7936
End of assembler dump.
(gdb) info symbol 0x100005a8
puts in section .text of /home/aditya/gdb_tests/simple_test
(gdb) info address printf
Symbol "printf" is at 0xd0133760 in a file compiled without debugging.
(gdb)

So in linux when I turn on debug symfile and while it is about to execute printf I see
qf->find_pc_sect_compunit_symtab (simple_test, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (ld64.so.2, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (system-supplied DSO at 0x7ffff7f80000, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libc.so.6, 0x7fff84091768, 0x7ffff7d7a96b, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL

So I am thinking that find_pc_sect_compunit_symtab () must return NULL. In AIX as well it is returning NULL after applying current patch.

qf->find_pc_sect_compunit_symtab (libc.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (simple_test, 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libcrypt.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (libc.a(shr.o), 0x1104a3c00, 0x100005a8, 0x0, 1)
qf->find_pc_sect_compunit_symtab (...) = NULL
qf->find_pc_sect_compunit_symtab (simple_test, 0x1104a3b70, 0x1000053c, 0x0, 0)
qf->find_pc_sect_compunit_symtab (...) = /home/aditya/gdb_tests/simple_test.c

So I think at least we are in the right direction. Let me know what you think of this and I will proceed according to the guidance received.

Awaiting a reply.

Have a nice day ahead.

Thanks and regards,
Aditya.

From: Tom Tromey <tom@tromey.com>
Date: Friday, 14 April 2023 at 8:15 PM
To: Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom Tromey <tom@tromey.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>, Aditya Kamath1 <Aditya.Kamath1@ibm.com>, Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>, simon.marchi@efficios.com <simon.marchi@efficios.com>
Subject: [EXTERNAL] Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning
>>>>> Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org> writes:

>> warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.)

Hi. Thanks for the reply.

> But the libc shared library that gives the printf () was compiled
> using stabs. So now we have symtab created for symbols used by our
> code and psymtab created for the shared library functions.

Ok. This answers one of my questions.

The stabs reader is on life support. If you want to track down and fix
this bug, it's up to you.

Actually I'm curious how important stabs are to your organization. I
would like to deprecate stabs in gdb 14 and remove them entirely in gdb
15. However, they are still required for AIX, I suppose we'd keep the
code around as long as you need.

> The problem is the shared library functions in AIX do not have an
> entry in the symtab. They have in psymtab.

> Coming to solving this, I did try a few things in the last one
> week. Let me tell you all what I did and where I failed. I tried to
> add the symtab entry in the xcoffread.c file via record_minimal_symbol
> () but then realised that after initial scan GDB code was not coming
> here during execution. So it failed. I tried searching around
> solib-aix.c file if I can get a hint to fix this but did not find any.

gdb reads 3 kinds of symbols.

"Minimal" symbols are essentially "linker symbols" -- in this case they
aren't super relevant. That's why your investigation here didn't yield
anything.

Partial symbols are made by an initial scan of the debug info. (The
DWARF reader doesn't use these any more but has its own analogous idea.)

When more information is needed about a partial symbol, full symbols are
read for the compilation unit.

The warning you are seeing means that the partial and full symbol
readers disagree. This is a bug somewhere.

Maybe the fix is to ensure a symbol is made in the full reader. It's
also possible that the fix is to not make a partial symbol.

Finding the issue isn't always very easy, but basically what you want to
do is inspect the point at which the relevant partial symbol is made;
then expand the CU; and finally see why the full reader doesn't make a
corresponding symbol.

TBH all of this stuff is a design flaw. In the DWARF reader I hope to
unify the paths so that this kind of mismatch is impossible.

Tom

[-- Attachment #2: 0001-Fix-PC-read-in-psymtab-but-not-in-symtab-warning-for.patch --]
[-- Type: application/octet-stream, Size: 1881 bytes --]

From f6946fe2a85ed2926a5de8cfc3ea305a5669deb0 Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Mon, 17 Apr 2023 07:36:46 -0500
Subject: [PATCH] Fix PC read in psymtab but not in symtab warning for AIX

In AIX on running next command in shared library we see psymtab PC is
found but not in symtab warnings.

This is because of some false psymtab entries.

In this patch I have removed the same and the GDB base testsuite numbers remain unchanged.
---
gdb/xcoffread.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gdb/xcoffread.c b/gdb/xcoffread.c
index c96cf551c99..3576408242a 100644
--- a/gdb/xcoffread.c
+++ b/gdb/xcoffread.c
@@ -2504,14 +2504,14 @@ scan_xcoff_symtab (minimal_symbol_reader &reader,
case 'G':
/* The addresses in these entries are reported to be
wrong. See the code that reads 'G's for symtabs. */
- pst->add_psymbol (gdb::string_view (namestring,
+ /* pst->add_psymbol (gdb::string_view (namestring,
p - namestring),
true, VAR_DOMAIN, LOC_STATIC,
SECT_OFF_DATA (objfile),
psymbol_placement::GLOBAL,
symbol.n_value,
psymtab_language,
- partial_symtabs, objfile);
+ partial_symtabs, objfile); */
continue;

case 'T':
@@ -2671,14 +2671,14 @@ scan_xcoff_symtab (minimal_symbol_reader &reader,
errors. */
if (startswith (namestring, "@FIX"))
continue;
- pst->add_psymbol (gdb::string_view (namestring,
+ /* pst->add_psymbol (gdb::string_view (namestring,
p - namestring),
true, VAR_DOMAIN, LOC_BLOCK,
SECT_OFF_TEXT (objfile),
psymbol_placement::GLOBAL,
symbol.n_value,
psymtab_language,
- partial_symtabs, objfile);
+ partial_symtabs, objfile); */
continue;

/* Two things show up here (hopefully); static symbols of
--
2.38.3