Hi Tom, Ulrich and community, Continuing our discussion on this warning that was pointed out. > warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) While we were fixing the call command this was pointed out. I have figured out the root cause of the same. In AIX whenever we use a shared library function like printf () or pthread_create () and do a next command to execute them we see this warning flooded in our output. For example in the program, (gdb) list 2 int global_variable = 2; 3 int main(){ 4 int local_variable = 1; 5 printf ("Simple print statement \n"); 6 printf ("Hello Bengaluru \n"); 7 return 0; 8 } When we execute this code using AIX GDB, Reading symbols from /home/aditya/gdb_tests/simple_test... (gdb) n The program is not being run. (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) (gdb) n 5 printf ("Simple print statement \n"); (gdb) warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) Simple print statement 6 printf ("Hello Bengaluru \n"); (gdb) Kindly note that my program in compiled {simple_test.c} with dwarf. 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. The problem is the shared library functions in AIX do not have an entry in the symtab. They have in psymtab. Consider the partial disassembly output of this code. 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>: warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.) 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) Now consider the below outputs (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) info sharedlibrary From To Syms Read Shared Object Library 0xd05bb240 0xd05bb9a1 Yes (*) /usr/lib/libcrypt.a(shr.o) 0xd0100e00 0xd0575123 Yes (*) /usr/lib/libc.a(shr.o) (*): Shared library is missing debugging information. (gdb) The PC address 0x100005a8 is the puts address. This address is written in symtab via xcoffread.c file. This is done in the initial scan via the read_minimal_symbol () in the initial scan itself. When GDB tries to execute printf (), what happens is the PC address 0x100005a8 is searched for in the find_pc_sect_line () function. Since the address 0x100005a8 is mst_solib_trampoline the condition if (msymbol.minsym->type () == mst_solib_trampoline) will satisfy and we will get the msymfunc address as 0xd0133760 which is the address of printf () in the shared library. We can see in info shared library output pasted above that the address 0xd0133760 is in the range of the libc shared library. So now GDB goes in search of this address 0xd0133760 in the symtab. Obviously, it will not find it. So then GDB will look into the psymtab and then find out. So GDB got surprised that how come this address 0x100005a8 is not there in symtab but we managed to get the symtab and line for it in the psymtab. Hence it prints this warning. So the root cause is we do not have a symtab entry for the printf () with address 0xd0133760 and we need to do the same. Looking at the Linux “maint print symbols” command output we see, Symtab for file /usr/include/stdio.h at 0x1002f30e550 Compilation directory is /home/aditya Read from object file /home/aditya/simple_test (0x1002f23bb10) Language: c Blockvector same as owning compunit: simple_test.c But this is not seen in AIX. So this should confirm that the root cause of these warnings are the fact that we do not create the shared library function addresses in the symtab or rather say the symtab for shared libray functions does not exist. So this is my detailed explanation. 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. I am a expanding my knowledge in GDB and I need your guidance on the right method for solve this problem using existing functions within GDB might be providing and most importantly the right place to fix this. This is where I am struggling. Since you are all an expert in this, kindly guide me on how we can fix this for GDB. What is right approach to fix this? Has any other target/OS seen such an issue. And if it has can you let me know how they fixed it. That patch with the examples of how to add symbol to the symtab and when to add in a shared library case will be a nice learning and useful for me to fix this for GDB. Let me know what you think of my explanation and let me know if you need more information to guide me. Hoping for a reply soon and waiting. Have a nice day ahead. Thanks and regards, Aditya. From: Tom Tromey Date: Thursday, 24 November 2022 at 11:45 PM To: Aditya Kamath1 Cc: Ulrich Weigand , gdb-patches@sourceware.org , tom@tromey.com , Sangamesh Mallayya , Sanket Rathi , simark@simark.ca Subject: [EXTERNAL] Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX >>> warning: (Internal error: pc 0x10000290 in read in psymtab, but not in symtab.) >> This normally indicates a serious bug. Also, I guess you must be using >> stabs? > By the way I use DWARF for all the tests I do. DWARF no longer creates psymtabs, and that warning is only emitted by the psymtab code, so something is off here. > So, I had been searching for TYPE_CODE_FIXED_POINT. Unfortunately, > when I tried running the Ada test cases for the same, the output was > that the test case is unsupported. I wonder though -- why was it unsupported? If you don't have an Ada compiler, then that's one thing; but if the test is doing some kind of platform check, then in a case like that you'd want to lift the restriction before trying. > One of the things about fixed point numbers is I have not found a way > I can write the same in C or C++ in AIX. It's not a C feature, so this can't be done. Tom