public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
To: Tom Tromey <tom@tromey.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	"tom@tromey.com" <tom@tromey.com>,
	Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>,
	"simon.marchi@efficios.com" <simon.marchi@efficios.com>
Subject: RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab  warning
Date: Fri, 14 Apr 2023 07:38:11 +0000	[thread overview]
Message-ID: <CH2PR15MB35447B6A82AAF93FFA7C6527D6989@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <87r0xsb4np.fsf@tromey.com>

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

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 <puts>
   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 <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)

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 <tom@tromey.com>
Date: Thursday, 24 November 2022 at 11:45 PM
To: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>, gdb-patches@sourceware.org <gdb-patches@sourceware.org>, tom@tromey.com <tom@tromey.com>, Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>, Sanket Rathi <sanrathi@in.ibm.com>, simark@simark.ca <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

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 34540 bytes --]

  reply	other threads:[~2023-04-14  7:38 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07 11:00 [PATCH] Fix call functions command bug in 64-bit programs for AIX Aditya Kamath1
2022-11-08 13:30 ` Ulrich Weigand
2022-11-11 17:53   ` Aditya Kamath1
2022-11-14 15:54     ` Ulrich Weigand
2022-11-14 17:32       ` Aditya Kamath1
2022-11-14 18:19         ` Ulrich Weigand
2022-11-14 18:28           ` Aditya Kamath1
2022-11-14 18:43             ` Ulrich Weigand
2022-11-14 18:52               ` Aditya Kamath1
2022-11-14 19:10                 ` Ulrich Weigand
2022-11-16 11:27                   ` Aditya Kamath1
2022-11-16 15:15                     ` Ulrich Weigand
2022-11-16 18:07                       ` Aditya Kamath1
2022-11-16 18:30                         ` Tom Tromey
2022-11-17 12:54                         ` Ulrich Weigand
2022-11-24 17:56                           ` Aditya Kamath1
2022-11-24 18:15                             ` Tom Tromey
2023-04-14  7:38                               ` Aditya Kamath1 [this message]
2023-04-14 14:45                                 ` [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning Tom Tromey
2023-04-17 13:08                                   ` Aditya Kamath1
2023-04-17 13:16                                     ` Aditya Kamath1
2023-04-18 10:12                                       ` Ulrich Weigand
2023-04-21 13:00                                         ` Aditya Kamath1
2023-04-24 15:44                                           ` Ulrich Weigand
2023-04-27 10:13                                             ` Aditya Kamath1
2023-04-27 12:23                                               ` Ulrich Weigand
2023-04-27 10:14                                   ` Aditya Kamath1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CH2PR15MB35447B6A82AAF93FFA7C6527D6989@CH2PR15MB3544.namprd15.prod.outlook.com \
    --to=aditya.kamath1@ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.com \
    --cc=simon.marchi@efficios.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).