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>,
	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: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab  warning
Date: Mon, 17 Apr 2023 13:08:38 +0000	[thread overview]
Message-ID: <CH2PR15MB354419F887A949497D3FF070D69C9@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <87sfd24j4w.fsf@tromey.com>


[-- Attachment #1.1: Type: text/plain, Size: 10389 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.

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


  reply	other threads:[~2023-04-17 13:08 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                               ` [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning Aditya Kamath1
2023-04-14 14:45                                 ` Tom Tromey
2023-04-17 13:08                                   ` Aditya Kamath1 [this message]
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=CH2PR15MB354419F887A949497D3FF070D69C9@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).