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 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 0x1000053c <+36>: lwz r2,20(r1) 0x10000540 <+40>: lwz r3,72(r2) 0x10000544 <+44>: bl 0x100005a8 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 Date: Friday, 14 April 2023 at 8:15 PM To: Aditya Kamath1 via Gdb-patches Cc: Tom Tromey , Ulrich Weigand , Aditya Kamath1 , Sangamesh Mallayya , 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 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