Hi Tom, >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. We are okay with you removing the stabs debugging in GDB 15. 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