[PATCH] Fix call functions command bug in 64-bit programs for AIX

[PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

[-- Attachment #1.1: Type: text/plain, Size: 2366 bytes --]

Hi all,

AIX folks while attempting to debug 64-bit programs using the call command are unable to receive and send the correct return value and parameter info in the program.

The issue can be replicated in the below program:-

#include <stdio.h>


long longit (long a)

{

  printf ("long val = %ld \n", a);

  return a;


}


int intit (int a)

{

  printf ("int val = %d \n", a);

  return a;


}


int main ()

{

  intit (27);

  longit (33);

}

The output before the patch is

Reading symbols from /home/xyz/gdb_tests/callfuncs...

(gdb) b main

Breakpoint 1 at 0x10000780: file /home/xyz/gdb_tests/callfuncs.c, line 19.

(gdb) r

Starting program: /home/xyz/gdb_tests/callfuncs

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main () at /home/xyz/gdb_tests/callfuncs.c:19

19        intit (27);

(gdb) call intit (21)

int val = 0

$1 = 0

(gdb) q


The output should have been 21 but is not.

The output after applying this patch:-

Reading symbols from /home/XYZ/gdb_tests/callfuncs...

(gdb) b main

Breakpoint 1 at 0x100005f0: file /home/XYZ/gdb_tests/callfuncs.c, line 19.

(gdb) r

Starting program: /home/XYZ/gdb_tests/callfuncs


Breakpoint 1, main () at /home/XYZ/gdb_tests/callfuncs.c:19

19        intit (27);

(gdb) call intit (21)

int val = 21

$1 = 21

(gdb) q


Why does this happen??
The issue is that when a user attempts to test the return type or print statements via the call "FUNC_NAME (parameter A, parameter B)" command, any input be it parameter A or B is taken in little endian format from the GDB cache. But AIX is using Big endian format.

For example, if we have a value 21 as type long then the higher 32 bits [ which is 0 in number 21] were stored in lower 32 bits and lower 32 bits [ represent 21 in the number 21] is stored in higher 32 bits.

Please find attached the patch. [See:- 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch]

In the patch I have written comments on further details.

Kindly let us know if this solution works, if not let us know a better way to handle the same.

Have a nice day ahead.

Thanks and regards,
Aditya.




[-- Attachment #2: 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch --]
[-- Type: application/octet-stream, Size: 6727 bytes --]

From 7d842b6c956840f78871570207f15cf76a4b2354 Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Mon, 7 Nov 2022 04:53:15 -0600
Subject: [PATCH] Fix call functions command bug in 64-bit programs for AIX

The issue is that when a user attempts to test the return type or print statements via the

call FUNCNAME with parameters command

any input be it parameter A or B is taken in little endian format from the GDB cache

 But AIX is using Big endian format

This patch fixes the same issue
---
 gdb/rs6000-aix-nat.c | 146 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 108 insertions(+), 38 deletions(-)

diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c
index cb141427696..99e8af03877 100644
--- a/gdb/rs6000-aix-nat.c
+++ b/gdb/rs6000-aix-nat.c
@@ -194,6 +194,7 @@ fetch_register (struct regcache *regcache, int regno)
 {
   struct gdbarch *gdbarch = regcache->arch ();
   int addr[PPC_MAX_REGISTER_SIZE];
+  long long addr64[PPC_MAX_REGISTER_SIZE];
   int nr, isfloat;
   pid_t pid = regcache->ptid ().pid ();
 
@@ -228,14 +229,19 @@ fetch_register (struct regcache *regcache, int regno)
 	  long long buf;
 	  rs6000_ptrace64 (PT_READ_GPR, pid, nr, 0, &buf);
 	  if (register_size (gdbarch, regno) == 8)
-	    memcpy (addr, &buf, 8);
+	    memcpy (addr64, &buf, 8);
 	  else
-	    *addr = buf;
+	    *addr64 = buf;
 	}
     }
 
   if (!errno)
-    regcache->raw_supply (regno, (char *) addr);
+  {
+    if (!ARCH64 ())
+      regcache->raw_supply (regno, (char *) addr);
+    else
+      regcache->raw_supply (regno, (char *) addr64);
+  }
   else
     {
 #if 0
@@ -252,57 +258,121 @@ static void
 store_register (struct regcache *regcache, int regno)
 {
   struct gdbarch *gdbarch = regcache->arch ();
-  int addr[PPC_MAX_REGISTER_SIZE];
-  int nr, isfloat;
-  pid_t pid = regcache->ptid ().pid ();
-
-  /* Fetch the register's value from the register cache.  */
-  regcache->raw_collect (regno, addr);
-
-  /* -1 can be a successful return value, so infer errors from errno.  */
+  int addr32[PPC_MAX_REGISTER_SIZE];
+  long addr64[PPC_MAX_REGISTER_SIZE];
+  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
+  CORE_ADDR addr;
+  CORE_ADDR original_addr;
+  size_t size;
+  gdb_byte *little_end_buf;
+  pid_t pid;
+  int i;
+  int isfloat;
+  long big_end_buf = INT_MIN;
   errno = 0;
 
-  nr = regmap (gdbarch, regno, &isfloat);
+  /* Get the address of the register.  */
+  addr = regmap (gdbarch, regno, &isfloat);
+
+  if (addr == (CORE_ADDR)-1
+      || gdbarch_cannot_store_register (gdbarch, regno))
+    return;
+ 
+  pid = regcache->ptid ().pid ();
+
+  size = register_size (gdbarch, regno);
+  little_end_buf = (gdb_byte *) alloca (size);
+
+  /* Register number R3 to R10 in AIX belongs to 
+     function parameters. If a user attempts to 
+     give input via call command and in 64 bit mode
+     the value in the buffer is little endian but
+     in AIX we use big endian.  Hence if R3 to R10
+     registers are used in 64 bit mode we need to 
+     re align from little endian to big endian.
+     Otherwise it can be in a 64 bit or 32 bit buffer
+     depending on the architecture bit mode of the 
+     user program.  */
+
+  if (regno <= 10 && regno >= 3 && ARCH64 ()) 
+    regcache->raw_collect (regno, little_end_buf);
+  else if (ARCH64 ())
+    regcache->raw_collect (regno, addr64);
+  else
+    regcache->raw_collect (regno, addr32);
+ 
+  /* Save the original address of the register.  */
+  original_addr = addr;
 
   /* Floating-point registers.  */
   if (isfloat)
-    rs6000_ptrace32 (PT_WRITE_FPR, pid, addr, nr, 0);
+    rs6000_ptrace32 (PT_WRITE_FPR, pid, *little_end_buf, addr, 0);
 
   /* Bogus register number.  */
-  else if (nr < 0)
+  if (addr < 0)
     {
       if (regno >= gdbarch_num_regs (gdbarch))
-	gdb_printf (gdb_stderr,
-		    "gdb error: register no %d not implemented.\n",
-		    regno);
+        gdb_printf (gdb_stderr,
+                    "gdb error: register no %d not implemented.\n",
+                    regno);
     }
+  /* Fixed-point registers in 32 bit mode.  */
+  else if (!ARCH64 ())
+    rs6000_ptrace32 (PT_WRITE_GPR, pid, (int *) addr, *addr32, 0);
 
-  /* Fixed-point registers.  */
+  /* Fixed-point registers in 64 bit mode.  */
   else
+  {
+    /* Function parameters to be changed from little to big endian.  */
+    if (regno <= 10 && regno >= 3)
     {
+      for (i = 0; i < size; i += sizeof (PTRACE_TYPE_RET))
+      {
+        size_t chunk = std::min (sizeof (PTRACE_TYPE_RET), size - i);
+        PTRACE_TYPE_RET val;
+
+        val = extract_unsigned_integer (little_end_buf + i, chunk, byte_order);
+        errno = 0;
+         
+        /* Realign chunck by chunk in 8 bits.  */
+   
+        if (register_size (gdbarch, regno) == 8)
+        {
+          if (val != 0)
+          {
+            /* Either higher 32 bits or higher 32 bits are 0.  */
+            if (big_end_buf == INT_MIN || big_end_buf == 0)
+              big_end_buf = val;
+
+            /* Lower 32 bits.  */
+            else if (big_end_buf != INT_MIN)
+            {
+              big_end_buf <<= 8;
+              big_end_buf |= val;
+            }
+          }
+
+          /* Copy 0 only if the actual value is  0.  */
+          else if (val == 0 && big_end_buf == INT_MIN)
+            big_end_buf = val;
+        }
+        else
+          big_end_buf = val;
+        addr += sizeof (PTRACE_TYPE_RET);
+      }
+
       /* The PT_WRITE_GPR operation is rather odd.  For 32-bit inferiors,
-	 the register's value is passed by value, but for 64-bit inferiors,
-	 the address of a buffer containing the value is passed.  */
-      if (!ARCH64 ())
-	rs6000_ptrace32 (PT_WRITE_GPR, pid, (int *) nr, *addr, 0);
-      else
-	{
-	  /* PT_WRITE_GPR requires the buffer parameter to point to an 8-byte
-	     area, even if the register is really only 32 bits.  */
-	  long long buf;
-	  if (register_size (gdbarch, regno) == 8)
-	    memcpy (&buf, addr, 8);
-	  else
-	    buf = *addr;
-	  rs6000_ptrace64 (PT_WRITE_GPR, pid, nr, 0, &buf);
-	}
-    }
+         the register's value is passed by value, but for 64-bit inferiors,
+         the address of a buffer containing the value is passed.  */
 
-  if (errno)
-    {
-      perror (_("ptrace write"));
-      errno = 0;
+      /* PT_WRITE_GPR requires the buffer parameter to point to an 8-byte
+         area, even if the register is really only 32 bits.  */
+
+      rs6000_ptrace64 (PT_WRITE_GPR, pid, (long *)original_addr, 0, &big_end_buf);
     }
+    else
+      rs6000_ptrace64 (PT_WRITE_GPR, pid, (long *)original_addr, 0, addr64);
+  }
 }
 
 /* Read from the inferior all registers if REGNO == -1 and just register
-- 
2.31.1

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>The issue is that when a user attempts to test the return type or print
>statements via the call "FUNC_NAME (parameter A, parameter B)" command,
any input be it parameter A or B is taken in little endian format from
>the GDB cache. But AIX is using Big endian format. 

>For example, if we have a value 21 as type long then the higher 32 bits
>[ which is 0 in number 21] were stored in lower 32 bits and lower 32 bits
>[ represent 21 in the number 21] is stored in higher 32 bits.

This is not how the GDB register cache is working.  Can you explain in
more detail what exactly you're refering to here?

The register cache holds a sequence of bytes for each register.  The
number of bytes in the cache depends on the size of that register as
defined by the architecture.  The contents of those bytes are *always*
assumed to be in big-endian byte order on AIX.

For 64-bit inferior processes, GDB assumes that the ptrace call
always uses a 64-bit buffer, even if the register size is only 4.
To handle these cases, the current code will convert between the
two formats, which looks correct to me: in the fetch_register
case, it will retrieve an 8-byte value from ptrace, convert that
value (correctly, also for big-endian) to an 4-byte value, and
pass that 4-byte value to raw_supply, which should expect 4 bytes
in this case because the register_size is 4.

To understand what's going on exactly I need more details:
- what does ARCH64() return?
- what does register_size(...) return for those registers?
  (for GPRs with a 64-bit inferior it should return 8, if
  it doesn't that's probably the root cause of the problem)
- what value does ptrace return in your case?


In any case, explicitly listing specific register numbers by ABI
is definitely wrong here.  This routine must correctly handle
any register, it does not matter what the ABI usage is.


Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

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

Hi Ulrich,

> This is not how the GDB register cache is working.  Can you explain in
> more detail what exactly you're refering to here?

Let us say we have a simple function, like print_Num (int a, long b) which prints these numbers a and b and the program is in 64-bit mode. If the programs are debugged normally, things work fine. But if a user attempts to see what the function does with the command call print_Num (int a, long b) then in the register assigned for function parameters the value 0 is getting dumped. What is happening is the pointer that is pointing to the input numbers a and b in the regcache->raw_supply which was addr previously is not aliging our values. It dumps the higher 32 bits in lower 32 bits and lower 32 bits to the higher which I figured out when I extracted it byte by byte using long pointer [long addr64 variable in the patch]. If int pointer is used in 64-bit mode in raw_supply code's second parameter, then memcpy () before rs6000_ptrace64 () fails to copy the right 8 bytes in buffer as int addr[64] is pointing to the wrong information. Overall, we were not pointing to the right place with the pointers passed to these functions.

>- what does ARCH64() return?
True in 64 bit mode and false in 32 bit mode

> - what does register_size(...) return for those registers?
8 in 64 bit mode, 4 in 32 bit mode
  (for GPRs with a 64-bit inferior it should return 8, if
  it doesn't that's probably the root cause of the problem)
> - what value does ptrace return in your case?
It returns the data parameter value that is passed as the calls are successful.

Consider this code below:-


#include "stdio.h"

int num2print(long num, float num2, int num3, double num4) {

  if (num == 0) {

    printf("R0\n");

    return 0;

  }


  if (num == 1) {

    printf("R1\n");

    return 1;

  }

  printf("R%d\n",num);

  printf("R%f\n",num2);

  printf("R%d\n",num3);

  printf("R%lf\n",num4);

  return num;

}


int main(int argc, char** argv)


{

  printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

  return 0;

}


The output before patch in 64 bit mode is:-


Reading symbols from /home/XYZ...

(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ.c, line 22.

(gdb) r

Starting program: /home/XYZ

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0) at /home/XYZ.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, double)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 5)

R2

R3.000000

R0

R5.000000

$2 = 2

(gdb)



The output highlighted in bold should have been R4 but is R0.. The datatype of the variable is long and if you print the output byte by byte before memcpy and if you have taken a long pointer to raw_supply, one realises 4 which is lower 32 bits is in higher bits and 0 in higher bits is in lower bits which was the pointer will be holding. The pointer getting the value in raw_supply was pointing to elsewhere instead of 4 [ the lower bits] if it is an int pointer.


Kindly let me know if you need more details. I am only trying to re align to correct the things my pointer in raw_supply function has messed up. Let me know if there can be a better way you have in mind.

Have a nice day.

Thanks and regards,
Aditya.




________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 08 November 2022 19:00
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>The issue is that when a user attempts to test the return type or print
>statements via the call "FUNC_NAME (parameter A, parameter B)" command,
any input be it parameter A or B is taken in little endian format from
>the GDB cache. But AIX is using Big endian format.

>For example, if we have a value 21 as type long then the higher 32 bits
>[ which is 0 in number 21] were stored in lower 32 bits and lower 32 bits
>[ represent 21 in the number 21] is stored in higher 32 bits.

This is not how the GDB register cache is working.  Can you explain in
more detail what exactly you're refering to here?

The register cache holds a sequence of bytes for each register.  The
number of bytes in the cache depends on the size of that register as
defined by the architecture.  The contents of those bytes are *always*
assumed to be in big-endian byte order on AIX.

For 64-bit inferior processes, GDB assumes that the ptrace call
always uses a 64-bit buffer, even if the register size is only 4.
To handle these cases, the current code will convert between the
two formats, which looks correct to me: in the fetch_register
case, it will retrieve an 8-byte value from ptrace, convert that
value (correctly, also for big-endian) to an 4-byte value, and
pass that 4-byte value to raw_supply, which should expect 4 bytes
in this case because the register_size is 4.

To understand what's going on exactly I need more details:
- what does ARCH64() return?
- what does register_size(...) return for those registers?
  (for GPRs with a 64-bit inferior it should return 8, if
  it doesn't that's probably the root cause of the problem)
- what value does ptrace return in your case?


In any case, explicitly listing specific register numbers by ABI
is definitely wrong here.  This routine must correctly handle
any register, it does not matter what the ABI usage is.


Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>>- what does ARCH64() return?
>True in 64 bit mode and false in 32 bit mode
>> - what does register_size(...) return for those registers?
>8 in 64 bit mode, 4 in 32 bit mode
>  (for GPRs with a 64-bit inferior it should return 8, if
>  it doesn't that's probably the root cause of the problem)
>> - what value does ptrace return in your case?
>It returns the data parameter value that is passed as the calls are successful. 

Did you actually verify any of this information?
I.e. by debugging GDB itself, or by adding debug print
statements to store_register?

I'm asking because if the above is all true, then your patch
to store_register is a complete no-op for this case:

Before your patch, you have:
  int addr[PPC_MAX_REGISTER_SIZE];
[...]
            memcpy (addr, &buf, 8);
[...]
    regcache->raw_supply (regno, (char *) addr);

After your patch, you have:
  long long addr64[PPC_MAX_REGISTER_SIZE];
[...]
           memcpy (addr64, &buf, 8);
[...]
      regcache->raw_supply (regno, (char *) addr64);

which is exactly the same!  Note that both the place
that stores into addr[64] and the place that uses it
cast to (char *), so whether you declare the array
as int or long long does not make any difference
whatsoever.

Therefore, I believe that something else must be
going on that is actually causing the problem
you're seeing.  You really need to debug the
actual behavior in store_register to understand
what is in fact going on here.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

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

Hi Ulrich,

>Did you actually verify any of this information?
>I.e. by debugging GDB itself, or by adding debug print
>statements to store_register?

>I'm asking because if the above is all true, then your patch
>to store_register is a complete no-op for this case:

I understand. No problem. Let me make it easier. So, consider a program with a function num2print () which print the number we pass prefixed with a R. For example, if we pass 2, it prints R2, 3 it will print R3. Please find the program at the bottom of this email.

I have added a print statement for what we get in *addr via raw_supply and what we copy in long buf that will go in the ptrace. Also, I print the regno. As a fact register number R3 to R10 are reserved for function parameters.

So, the GDB output for the program below is as follows:_


(gdb) b main

Breakpoint 1 at 0x100007e4: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (int, float, int, int)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 5)

val in regno 3 via buf is 0 and *addr is 2

val in regno 4 via buf is 0 and *addr is 1077936128

val in regno 5 via buf is 0 and *addr is 4

val in regno 6 via buf is 0 and *addr is 5

val in regno 1 via buf is -1696 and *addr is 268435455

val in regno 67 via buf is 1152 and *addr is 1

R0

$2 = 0


(gdb) info reg

r0             0x1000004f4         4294968564

r1             0xffffffffffff9e0   1152921504606845408

r2             0x1100002e0         4563403488

r3             0x1                 1

r4             0xffffffffffffad0   1152921504606845648

r5             0xffffffffffffae0   1152921504606845664

r6             0x800000000000d032  9223372036854829106

r7             0xfffffffffffffe0   1152921504606846944

r8             0x0                 0

r9             0x1                 1

r10            0x0                 0

r11            0x1030              4144

r12            0xf1000600005901d8  17365886760216232408

r13            0xbadc0ffee0ddf00d  13464654573299691533



Clearly from the GDB output the buffer value getting copied is 0 but *addr is 2.. So

memcpy (&buf, addr, 8);


has not copied the values properly and hence we don't get the desired value.. Kindly note these programs are run-in 64-bit mode only and in 32-bit mode we are good.

Now let's change the case. Let's make one of the parameters in the num2print function as long. The output for the same is as below in 64-bit mode..


(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, int)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 5)

val in regno 3 via buf is 2 and *addr is 0

val in regno 4 via buf is 0 and *addr is 1077936128

val in regno 5 via buf is 0 and *addr is 4

val in regno 6 via buf is 0 and *addr is 5


R2

R3.000000

R0

R0

$2 = 2


So, my first parameter is long, and rest are int, except the second.. Check this out..

The first parameter is pointing to 0 in *addr but is copied properly in buf which long and is 2.. This is beause *addr is pointing to higher 32 bits 0 and lower is 2 but somehow memcpy copied properly into the buf.
Our integer friends in regno 5 and 6  [parameter 3 and 4] are taken correctly in *addr but is horribly wrong after memcpy and what goes in buf..

So, the conclusions are long is fine, but int are gone for a toss. Also note our *addr is int..


(gdb) info reg

r0             0x1000004f4         4294968564

r1             0xffffffffffff9e0   1152921504606845408

r2             0x1100002d0         4563403472

r3             0x1                 1

r4             0xffffffffffffad0   1152921504606845648

r5             0xffffffffffffae0   1152921504606845664

r6             0x800000000000d032  9223372036854829106


what has gone in registers as a result of all this is garbage values.

I do not want to handle things in integer as then aliging integer becomes a mess in 64 bit mode. Now let's take int addr as long addr64[64] of what I have done in my patch [attached in my previous mail]. I am going to use the same program but will print byte by byte on what comes in my *addr64. Since it is long, I print lower 32 bits first and then higher 32 bits via my patch variable val..

The output is as follows after applying my patch:-


(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, int)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 5)

val = 0 in regno 3

val = 2 in regno 3

val = 0 in regno 33

val = 2 in regno 33

val = 1077936128 in regno 4

val = 0 in regno 4

val = 4 in regno 5

val = 0 in regno 5

val = 5 in regno 6

val = 0 in regno 6


R2

R3.000000

R4

R5

$2 = 2


Check the above output. I have printed my val byte by byte with higher bytes first and then lower bytes.

The first parameter was 2. The *addr64 which is a pointer of long type, is pointing to 0 which is higher 32 bits and then if we increment addr64 it is pointing to 2 which lower 32 bits.

The second parameter being float used FPR number 33 and GPR 4..

The third parameter being int is aligned correctly by addr64 of long type pointer. Lower bits pointing first which is 4 and higher bits pointing at addr64++ address. Technically this is how even the first parameter should have been aligned but it is in reverse.

Similarly, to the fourth parameter things align well.


So, this is what I am trying to convince that using int addr[64] isn't allowing memcpy to copy values into the buffer correctly. We rather use a long and align this correctly.

Let me know what you think. If you feel I can solve this in a better way, let me know. I appreciate your patience to read the email and wish to seek your guidance on the same.

Have a nice day ahead.

Thanks and regards,
Aditya.

---------------------------------------------------------------

PROGRAM


#include "stdio.h"

int num2print(int num, float num2, int num3, int num4) {

  if (num == 0) {

    printf("R0\n");

    return 0;

  }


  if (num == 1) {

    printf("R1\n");

    return 1;

  }

  printf("R%d\n",num);

  printf("R%f\n",num2);

  printf("R%d\n",num3);

  printf("R%d\n",num4);

  return num;

}


int main(int argc, char** argv)


{

  printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

  return 0;

}

 ----------------------------------------------------------------------





________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 14 November 2022 21:24
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>>- what does ARCH64() return?
>True in 64 bit mode and false in 32 bit mode
>> - what does register_size(...) return for those registers?
>8 in 64 bit mode, 4 in 32 bit mode
>  (for GPRs with a 64-bit inferior it should return 8, if
>  it doesn't that's probably the root cause of the problem)
>> - what value does ptrace return in your case?
>It returns the data parameter value that is passed as the calls are successful.

Did you actually verify any of this information?
I.e. by debugging GDB itself, or by adding debug print
statements to store_register?

I'm asking because if the above is all true, then your patch
to store_register is a complete no-op for this case:

Before your patch, you have:
  int addr[PPC_MAX_REGISTER_SIZE];
[...]
            memcpy (addr, &buf, 8);
[...]
    regcache->raw_supply (regno, (char *) addr);

After your patch, you have:
  long long addr64[PPC_MAX_REGISTER_SIZE];
[...]
           memcpy (addr64, &buf, 8);
[...]
      regcache->raw_supply (regno, (char *) addr64);

which is exactly the same!  Note that both the place
that stores into addr[64] and the place that uses it
cast to (char *), so whether you declare the array
as int or long long does not make any difference
whatsoever.

Therefore, I believe that something else must be
going on that is actually causing the problem
you're seeing.  You really need to debug the
actual behavior in store_register to understand
what is in fact going on here.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>I have added a print statement for what we get in *addr via raw_supply
>and what we copy in long buf that will go in the ptrace. Also, I print
>the regno. As a fact register number R3 to R10 are reserved for
>function parameters. 

Yes, of course just looking at "*addr" will be wrong in 64-bit mode,
but that doesn't matter since nobody is actually ever looking at
"*addr" in this case.

>(gdb) call num2print (2, 3, 4, 5)
>val in regno 3 via buf is 0 and *addr is 2 
>val in regno 4 via buf is 0 and *addr is 1077936128 
>val in regno 5 via buf is 0 and *addr is 4 
>val in regno 6 via buf is 0 and *addr is 5 
>val in regno 1 via buf is -1696 and *addr is 268435455 
>val in regno 67 via buf is 1152 and *addr is 1 

Can you show the specific debug code you have added to get this
output?

>(gdb) info reg
>r0             0x1000004f4         4294968564
>r1             0xffffffffffff9e0   1152921504606845408
>r2             0x1100002e0         4563403488
>r3             0x1                 1
>r4             0xffffffffffffad0   1152921504606845648
>r5             0xffffffffffffae0   1152921504606845664
>r6             0x800000000000d032  9223372036854829106
>r7             0xfffffffffffffe0   1152921504606846944
>r8             0x0                 0
>r9             0x1                 1
>r10            0x0                 0
>r11            0x1030              4144
>r12            0xf1000600005901d8  17365886760216232408
>r13            0xbadc0ffee0ddf00d  13464654573299691533

From what I can see these are the values after the
num2print routine has returned and the original
values were restored by GDB.

If you want to see the values *in num2print* you need
to set a breakpoint at num2print before calling it.


Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

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

Hi Ulrich,

>Can you show the specific debug code you have added to get this
>output?

I have added the printf in the

store_register (struct regcache *regcache, int regno)

function.. This is where ptrace will put the contents in the register..

I have pasted it below..

Have a nice day ahead.

Thanks and regards,
Aditya.


else

        {

          /* PT_WRITE_GPR requires the buffer parameter to point to an 8-byte

             area, even if the register is really only 32 bits.  */

          long long buf;

          if (register_size (gdbarch, regno) == 8)

            memcpy (&buf, addr, 8);

          else

            buf = *addr;

          printf ("val in regno = %d via buf is %d and *addr is %d\n", regno, bu

f, *addr);

          rs6000_ptrace64 (PT_WRITE_GPR, pid, nr, 0, &buf);

        }

________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 14 November 2022 23:49
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>; Sanket Rathi <sanrathi@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>I have added a print statement for what we get in *addr via raw_supply
>and what we copy in long buf that will go in the ptrace. Also, I print
>the regno. As a fact register number R3 to R10 are reserved for
>function parameters.

Yes, of course just looking at "*addr" will be wrong in 64-bit mode,
but that doesn't matter since nobody is actually ever looking at
"*addr" in this case.

>(gdb) call num2print (2, 3, 4, 5)
>val in regno 3 via buf is 0 and *addr is 2
>val in regno 4 via buf is 0 and *addr is 1077936128
>val in regno 5 via buf is 0 and *addr is 4
>val in regno 6 via buf is 0 and *addr is 5
>val in regno 1 via buf is -1696 and *addr is 268435455
>val in regno 67 via buf is 1152 and *addr is 1

Can you show the specific debug code you have added to get this
output?

>(gdb) info reg
>r0             0x1000004f4         4294968564
>r1             0xffffffffffff9e0   1152921504606845408
>r2             0x1100002e0         4563403488
>r3             0x1                 1
>r4             0xffffffffffffad0   1152921504606845648
>r5             0xffffffffffffae0   1152921504606845664
>r6             0x800000000000d032  9223372036854829106
>r7             0xfffffffffffffe0   1152921504606846944
>r8             0x0                 0
>r9             0x1                 1
>r10            0x0                 0
>r11            0x1030              4144
>r12            0xf1000600005901d8  17365886760216232408
>r13            0xbadc0ffee0ddf00d  13464654573299691533

From what I can see these are the values after the
num2print routine has returned and the original
values were restored by GDB.

If you want to see the values *in num2print* you need
to set a breakpoint at num2print before calling it.


Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>        {
>          /* PT_WRITE_GPR requires the buffer parameter to point to an 8-byte
>             area, even if the register is really only 32 bits.  */
>          long long buf;
>          if (register_size (gdbarch, regno) == 8)
>            memcpy (&buf, addr, 8);
>          else
>            buf = *addr;
>          printf ("val in regno = %d via buf is %d and *addr is %d\n", regno, bu
f, *addr);

This doesn't work - buf is a "long long", so you need to use "%lld" to print
it, not just "%d".  That's why the output for "buf" was wrong.

Also, please print the result of "register_size (gdbarch, regno)" as well,
so we know for sure which part of the if condition is actually taken.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

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

Hi Ulrich,

Sure. This is done..

The code is

  if (register_size (gdbarch, regno) == 8)

            memcpy (&buf, addr, 8);

          else

            buf = *addr;

          printf ("val in regno = %d via buf is %lld and *addr is %d, regsize =

%d\n", regno, buf, *addr, register_size (gdbarch, regno));

          rs6000_ptrace64 (PT_WRITE_GPR, pid, nr, 0, &buf);

        }


in store_register (struct regcache *regcache, int regno)...


The output is as shown below:-


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/aditya/gdb_tests.c:22

warning: Source file is more recent than executable.

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, int)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 6)

val in regno = 3 via buf is 2 and *addr is 0, regsize = 8

val in regno = 4 via buf is 4629700416936869888 and *addr is 1077936128, regsize = 8

val in regno = 5 via buf is 17179869184 and *addr is 4, regsize = 8

val in regno = 6 via buf is 25769803776 and *addr is 6, regsize = 8....

R2

R3.000000

R0

R0.000000

$2 = 2


I have cut short those print statements.. Full output is below

Have a nice day ahead..

Thanks,
Aditya..

--------------------


22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, int)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 6)

val in regno = 3 via buf is 2 and *addr is 0, regsize = 8

val in regno = 4 via buf is 4629700416936869888 and *addr is 1077936128, regsize = 8

val in regno = 5 via buf is 17179869184 and *addr is 4, regsize = 8

val in regno = 6 via buf is 25769803776 and *addr is 6, regsize = 8

val in regno = 1 via buf is 1152921504606845280 and *addr is 268435455, regsize = 8

val in regno = 67 via buf is 4294968448 and *addr is 1, regsize = 8

val in regno = 0 via buf is 4294968564 and *addr is 1, regsize = 8

val in regno = 1 via buf is 1152921504606845280 and *addr is 268435455, regsize = 8

val in regno = 2 via buf is 4563403472 and *addr is 1, regsize = 8

val in regno = 3 via buf is 2 and *addr is 0, regsize = 8

val in regno = 4 via buf is 4629700416936869888 and *addr is 1077936128, regsize = 8

val in regno = 5 via buf is 17179869184 and *addr is 4, regsize = 8

val in regno = 6 via buf is 25769803776 and *addr is 6, regsize = 8

val in regno = 7 via buf is 1152921504606846944 and *addr is 268435455, regsize = 8

val in regno = 8 via buf is 0 and *addr is 0, regsize = 8

val in regno = 9 via buf is 1 and *addr is 0, regsize = 8

val in regno = 10 via buf is 0 and *addr is 0, regsize = 8

val in regno = 11 via buf is 4144 and *addr is 0, regsize = 8

val in regno = 12 via buf is -1080857313497259912 and *addr is -251656704, regsize = 8

val in regno = 13 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 14 via buf is 1 and *addr is 0, regsize = 8

val in regno = 15 via buf is 1152921504606845648 and *addr is 268435455, regsize = 8

val in regno = 16 via buf is 1152921504606845664 and *addr is 268435455, regsize = 8

val in regno = 17 via buf is 576495942044221440 and *addr is 134225921, regsize = 8

val in regno = 18 via buf is 1152921504606846672 and *addr is 268435455, regsize = 8

val in regno = 19 via buf is 720575940110904384 and *addr is 167772159, regsize = 8

val in regno = 20 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 21 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 22 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 23 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 24 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 25 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 26 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 27 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 28 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 29 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 30 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 31 via buf is 1152921504606845408 and *addr is 268435455, regsize = 8

val in regno = 64 via buf is 4294969308 and *addr is 1, regsize = 8

val in regno = 65 via buf is -6917529027640897486 and *addr is -1610612736, regsize = 8

val in regno = 66 via buf is 1109656104 and *addr is 1109656104, regsize = 4

val in regno = 67 via buf is 4294968448 and *addr is 1, regsize = 8

val in regno = 68 via buf is 0 and *addr is 0, regsize = 8

val in regno = 69 via buf is 0 and *addr is 0, regsize = 4

val in regno = 70 via buf is 0 and *addr is 0, regsize = 4

val in regno = 64 via buf is 4294968992 and *addr is 1, regsize = 8

R2

R3.000000

R0

R0.000000

val in regno = 0 via buf is 4294968564 and *addr is 1, regsize = 8

val in regno = 1 via buf is 1152921504606845408 and *addr is 268435455, regsize = 8

val in regno = 2 via buf is 4563403472 and *addr is 1, regsize = 8

val in regno = 3 via buf is 1 and *addr is 0, regsize = 8

val in regno = 4 via buf is 1152921504606845648 and *addr is 268435455, regsize = 8

val in regno = 5 via buf is 1152921504606845664 and *addr is 268435455, regsize = 8

val in regno = 6 via buf is -9223372036854722510 and *addr is -2147483648, regsize = 8

val in regno = 7 via buf is 1152921504606846944 and *addr is 268435455, regsize = 8

val in regno = 8 via buf is 0 and *addr is 0, regsize = 8

val in regno = 9 via buf is 1 and *addr is 0, regsize = 8

val in regno = 10 via buf is 0 and *addr is 0, regsize = 8

val in regno = 11 via buf is 4144 and *addr is 0, regsize = 8

val in regno = 12 via buf is -1080857313497259912 and *addr is -251656704, regsize = 8

val in regno = 13 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 14 via buf is 1 and *addr is 0, regsize = 8

val in regno = 15 via buf is 1152921504606845648 and *addr is 268435455, regsize = 8

val in regno = 16 via buf is 1152921504606845664 and *addr is 268435455, regsize = 8

val in regno = 17 via buf is 576495942044221440 and *addr is 134225921, regsize = 8

val in regno = 18 via buf is 1152921504606846672 and *addr is 268435455, regsize = 8

val in regno = 19 via buf is 720575940110904384 and *addr is 167772159, regsize = 8

val in regno = 20 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 21 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 22 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 23 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 24 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 25 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 26 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 27 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 28 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 29 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 30 via buf is -4982089500409860083 and *addr is -1159983106, regsize = 8

val in regno = 31 via buf is 1152921504606845408 and *addr is 268435455, regsize = 8

val in regno = 64 via buf is 4294969308 and *addr is 1, regsize = 8

val in regno = 65 via buf is -6917529027640897486 and *addr is -1610612736, regsize = 8

val in regno = 66 via buf is 1109656104 and *addr is 1109656104, regsize = 4

val in regno = 67 via buf is 4294968564 and *addr is 1, regsize = 8

val in regno = 68 via buf is 0 and *addr is 0, regsize = 8

val in regno = 69 via buf is 0 and *addr is 0, regsize = 4

val in regno = 70 via buf is 0 and *addr is 0, regsize = 4

$2 = 2

(gdb)

val = 0 in regno 51

val = 0 in regno 52

val = 0 in regno 52

val = 0 in regno 53

val = 0 in regno 53

val = 0 in regno 54

val = 0 in regno 54

val = 0 in regno 55

val = 0 in regno 55

val = 0 in regno 56

val = 0 in regno 56

val = 0 in regno 57

val = 0 in regno 57

val = 0 in regno 58

val = 0 in regno 58

val = 0 in regno 59

val = 0 in regno 59

val = 0 in regno 60

val = 0 in regno 60

val = 0 in regno 61

val = 0 in regno 61

val = 0 in regno 62

val = 0 in regno 62


(gdb)

(gdb)




________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 15 November 2022 00:13
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>; Sanket Rathi <sanrathi@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>        {
>          /* PT_WRITE_GPR requires the buffer parameter to point to an 8-byte
>             area, even if the register is really only 32 bits.  */
>          long long buf;
>          if (register_size (gdbarch, regno) == 8)
>            memcpy (&buf, addr, 8);
>          else
>            buf = *addr;
>          printf ("val in regno = %d via buf is %d and *addr is %d\n", regno, bu
f, *addr);

This doesn't work - buf is a "long long", so you need to use "%lld" to print
it, not just "%d".  That's why the output for "buf" was wrong.

Also, please print the result of "register_size (gdbarch, regno)" as well,
so we know for sure which part of the if condition is actually taken.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>(gdb) call num2print (2, 3, 4, 6)
>val in regno = 3 via buf is 2 and *addr is 0, regsize = 8
>val in regno = 4 via buf is 4629700416936869888 and *addr is 1077936128, regsize = 8
>val in regno = 5 via buf is 17179869184 and *addr is 4, regsize = 8
>val in regno = 6 via buf is 25769803776 and *addr is 6, regsize = 8....

Thanks!

This indicates that value is already placed incorrectly
into the register cache, before store_register was even
called.

Looking at rs6000_push_dummy_call in rs6000-aix-tdep.c, I see:

>          /* Argument can fit in one register.  No problem.  */
>          gdb_byte word[PPC_MAX_REGISTER_SIZE];
>
>          memset (word, 0, reg_size);
>          memcpy (word, value_contents (arg).data (), len);
>          regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);

which places an "int" argument in the *high* bytes of a register
on a 64-bit system.   This seems clearly wrong, and would be the
root cause of the problem you're seeing.

I think you'll need to have a closer look at this function and
make sure it implements the AIX ABI correctly, in particular
also on 64-bit systems.  (You might want to have a look at the
ppc64_sysv_abi_push_dummy_call routine for comparison, which
implements the Linux 64-bit ABI; I understand this is similar
to the AIX ABI.)

I assume that once you've fixed the push_dummy_call implementation,
no changes to the store_register / fetch_register routines will
be needed at all.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

[-- Attachment #1.1: Type: text/plain, Size: 5362 bytes --]

Hi Ulrich,

>This indicates that value is already placed incorrectly
>into the register cache, before store_register was even
>called.

You were right about this. Thank you so much for your guidance.

Please find attached the new patch. See 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch.

In AIX for 64-bit programs, we need to zero extend variables of integer data type.

Otherwise, a zero will get dumped in the register as we memset our word to 0 and integer is not extended.

In this patch I changed the same. I have pasted the output and code below..

Let me know what you think.

Thanks and regards,
Aditya.

----------------------------------
Program:


int num2print(long num, float num2, int num3, double num4) {

  if (num == 0) {

    printf("R0\n");

    return 0;

  }


  if (num == 1) {

    printf("R1\n");

    return 1;

  }

  printf("R%ld\n",num);

  printf("R%f\n",num2);

  printf("R%d\n",num3);

  printf("R%lf\n",num4);

  return num;

}


int main(int argc, char** argv)


{

  printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

  return 0;

}

--------------------------------------
Output before patch in 64 bit mode


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, double)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3, 4, 5)

R2

R3.000000

R0

R5.000000

$2 = 2

(gdb)

--------------------------------------------
Output after patch in 32-bit mode


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x10000664: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests


Breakpoint 1, main (argc=1, argv=0x2ff22bf0)

    at /home/XYZ/gdb_tests.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, double)} 0x10000518 <num2print>

(gdb) call num2print (2, 3, 4, 5.43)

R2

R3.000000

R4

R5.430000

$2 = 2

(gdb)
------------------------------------

output after patch in 64-bit mode


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x100007dc: file /home/XYZ/gdb_tests.c, line 22.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:22

22        printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9));

(gdb) call num2print

$1 = {int (long, float, int, double)} 0x1000006a0 <num2print>

(gdb) call num2print (2, 3.5, 43, 56.2)

R2

R3.500000

R43

R56.200000

$2 = 2

(gdb)


________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 15 November 2022 00:40
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>; Sanket Rathi <sanrathi@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>(gdb) call num2print (2, 3, 4, 6)
>val in regno = 3 via buf is 2 and *addr is 0, regsize = 8
>val in regno = 4 via buf is 4629700416936869888 and *addr is 1077936128, regsize = 8
>val in regno = 5 via buf is 17179869184 and *addr is 4, regsize = 8
>val in regno = 6 via buf is 25769803776 and *addr is 6, regsize = 8....

Thanks!

This indicates that value is already placed incorrectly
into the register cache, before store_register was even
called.

Looking at rs6000_push_dummy_call in rs6000-aix-tdep.c, I see:

>          /* Argument can fit in one register.  No problem.  */
>          gdb_byte word[PPC_MAX_REGISTER_SIZE];
>
>          memset (word, 0, reg_size);
>          memcpy (word, value_contents (arg).data (), len);
>          regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);

which places an "int" argument in the *high* bytes of a register
on a 64-bit system.   This seems clearly wrong, and would be the
root cause of the problem you're seeing.

I think you'll need to have a closer look at this function and
make sure it implements the AIX ABI correctly, in particular
also on 64-bit systems.  (You might want to have a look at the
ppc64_sysv_abi_push_dummy_call routine for comparison, which
implements the Linux 64-bit ABI; I understand this is similar
to the AIX ABI.)

I assume that once you've fixed the push_dummy_call implementation,
no changes to the store_register / fetch_register routines will
be needed at all.

Bye,
Ulrich


[-- Attachment #2: 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch --]
[-- Type: application/octet-stream, Size: 1378 bytes --]

From 44c45c050bfc017e3fffc2d0bb762d2fa9affa7e Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Wed, 16 Nov 2022 04:30:59 -0600
Subject: [PATCH] Fix call functions command bug in 64 bits programs for AIX

In AIX for 64 bit programs we need to zero extend variables of integer data type.

Otherwise a zero will get dumped in the register as we memset our word to 0 and integer is not extended.

This patch is a fix for the same.
---
 gdb/rs6000-aix-tdep.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gdb/rs6000-aix-tdep.c b/gdb/rs6000-aix-tdep.c
index d47974b51d1..a7d174d8be8 100644
--- a/gdb/rs6000-aix-tdep.c
+++ b/gdb/rs6000-aix-tdep.c
@@ -400,7 +400,12 @@ rs6000_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
 	  gdb_byte word[PPC_MAX_REGISTER_SIZE];
 
 	  memset (word, 0, reg_size);
-	  memcpy (word, value_contents (arg).data (), len);
+          if (type->code () == TYPE_CODE_INT)
+                /* Sign or zero extend the "int" into a "word".  */
+                store_unsigned_integer (word, tdep->wordsize, byte_order,
+                                        unpack_long (type, value_contents (arg).data ()));
+          else
+		memcpy (word, value_contents (arg).data (), len);
 	  regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);
 	}
       ++argno;
-- 
2.31.1

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>In AIX for 64-bit programs, we need to zero extend variables of integer data type.

This looks much more reasonable, thanks!

Just a couple of remaining questions:

>          memset (word, 0, reg_size);
>-         memcpy (word, value_contents (arg).data (), len);
>+          if (type->code () == TYPE_CODE_INT)
>+                /* Sign or zero extend the "int" into a "word".  */
>+                store_unsigned_integer (word, tdep->wordsize, byte_order,
>+                                        unpack_long (type, value_contents (arg).data ()));
>+          else
>+               memcpy (word, value_contents (arg).data (), len);
>          regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);

Is it correct to handle *only* TYPE_CODE_INT here?

The corresponding code in the Linux ABI code has:
  else if ((type->code () == TYPE_CODE_INT
            || type->code () == TYPE_CODE_ENUM
            || type->code () == TYPE_CODE_BOOL
            || type->code () == TYPE_CODE_CHAR
            || type->code () == TYPE_CODE_PTR
            || TYPE_IS_REFERENCE (type))

It might not really be necessary to handle pointer and reference
types if those are always guaranteed to be word sized.  But I
think enum, bool, and char types should be handled.

Also, it would probably be preferable to use reg_size instead
of tdep->wordsize to be consistent.

Finally, there are still white space issues (use tabs instead
of 8 spaces, if there's just a single statement inside an if
it is indented only 2 spaces, not 4).

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

[-- Attachment #1.1: Type: text/plain, Size: 7402 bytes --]

Hi Ulrich,

Please find attached the new patch. See 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch.

>It might not really be necessary to handle pointer and reference
>types if those are always guaranteed to be word sized.  But I
>think enum, bool, and char types should be handled.

You were right. Thank you for pointing out. I have attached the outputs below. It works fine now.

>Also, it would probably be preferable to use reg_size instead
>of tdep->wordsize to be consistent.
This is changed..

>Finally, there are still white space issues (use tabs instead
>of 8 spaces, if there's just a single statement inside an if
>it is indented only 2 spaces, not 4).

I took care of it. Kindly check..

If all is fine, kindly push this patch to the community. Let me know in case I missed something otherwise.

Have a nice day ahead.

Thanks and regards,
Aditya.

--------------------------------
PROGRAM


#include "stdio.h"

#include <stdbool.h>

enum week {Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday} w;

int num2print(long num, float num2, int num3, double num4, enum week w, char c1, bool b1, char *mystring) {

  printf("R%ld\n",num);

  printf("R%f\n",num2);

  printf("R%d\n",num3);

  printf("R%lf\n",num4);

  printf ("Day number passed is %d\n",w);

  printf ("R%c\n", c1);

  printf ("R%d\n", b1);

  printf ("FIFA winner is %s \n", mystring);

  return num;

}


int main(int argc, char** argv)


{

  enum week today = Wednesday;

  char fifaWinner[] = "Germany";

  bool x = false;

  printf("Hi Bangalore %x\n",num2print(27, 16, 13, 9.9, today, 'a', x, fifaWinner));

  return 0;

}

--------------------------------------
32 bit output before patch..


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x1000067c: file /home/XYZ/gdb_tests.c, line 19.

(gdb) r

Starting program: /home/XYZ/gdb_tests


Breakpoint 1, main (argc=1, argv=0x2ff22bf0)

    at /home/aditya/XYZ.c:19

19        enum week today = Wednesday;

(gdb) n

20        char fifaWinner[] = "Germany";

(gdb)

21        bool x = false;

(gdb) call num2print

$1 = {int (long, float, int, double, enum week, char, _Bool,

    char *)} 0x10000518 <num2print>

(gdb) call num2print (2, 3.4, 5, 6.7, Wednesday, 'c', 1, fifaWinner)

R2

R3.400000

R5

R6.700000

Day number passed is 3

Rc

R1

FIFA winner is Germany

warning: (Internal error: pc 0x10000290 in read in psymtab, but not in symtab.)


$2 = 2

-----------------------------------------------------------

64 bit output before patch


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x10000818: file /home/XYZ/gdb_tests.c, line 19.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:19

19        enum week today = Wednesday;

(gdb) n

20        char fifaWinner[] = "Germany";

(gdb)

21        bool x = false;

(gdb) call num2print (2, 3.4, 5, 6.7, Wednesday, 'c', 1, fifaWinner)

R2

R3.400000

R0

R6.700000

Day number passed is 0

R

R0

FIFA winner is Germany

$1 = 2

(gdb)

-------------------------------------------------------------------------

32-bit output after patch


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x1000067c: file /home/XYZ/gdb_tests.c, line 19.

(gdb) r

Starting program: /home/XYZ/gdb_tests


Breakpoint 1, main (argc=1, argv=0x2ff22bf0)

    at /home/XYZ/gdb_tests.c:19

19        enum week today = Wednesday;

(gdb) n

20        char fifaWinner[] = "Germany";

(gdb)

21        bool x = false;

(gdb) call num2print (2, 3.4, 5, 6.7, Wednesday, 'c', 1, fifaWinner)

R2

R3.400000

R5

R6.700000

Day number passed is 3

Rc

R1

FIFA winner is Germany

$1 = 2

(gdb)


-----------------------------------------------------


64-bit output after patch


Reading symbols from /home/XYZ/gdb_tests...

(gdb) b main

Breakpoint 1 at 0x10000818: file /home/XYZ/gdb_tests.c, line 19.

(gdb) r

Starting program: /home/XYZ/gdb_tests

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2

BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b


Breakpoint 1, main (argc=1, argv=0xffffffffffffad0)

    at /home/XYZ/gdb_tests.c:19

19        enum week today = Wednesday;

(gdb) n

20        char fifaWinner[] = "Germany";

(gdb) n

21        bool x = false;

(gdb) call num2print (2, 3.4, 5, 6.7, Wednesday, 'c', 1, fifaWinner)

R2

R3.400000

R5

R6.700000

Day number passed is 3

Rc

R1

FIFA winner is Germany

$1 = 2

(gdb) call num2print (2, 3.4, 5, 6.7, Wednesday, 'e', 0, fifaWinner)

R2

R3.400000

R5

R6.700000

Day number passed is 3

Re

R0

FIFA winner is Germany

warning: (Internal error: pc 0x100000480 in read in psymtab, but not in symtab.)


$2 = 2

(gdb)






________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 16 November 2022 20:45
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>; Sanket Rathi <sanrathi@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>In AIX for 64-bit programs, we need to zero extend variables of integer data type.

This looks much more reasonable, thanks!

Just a couple of remaining questions:

>          memset (word, 0, reg_size);
>-         memcpy (word, value_contents (arg).data (), len);
>+          if (type->code () == TYPE_CODE_INT)
>+                /* Sign or zero extend the "int" into a "word".  */
>+                store_unsigned_integer (word, tdep->wordsize, byte_order,
>+                                        unpack_long (type, value_contents (arg).data ()));
>+          else
>+               memcpy (word, value_contents (arg).data (), len);
>          regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);

Is it correct to handle *only* TYPE_CODE_INT here?

The corresponding code in the Linux ABI code has:
  else if ((type->code () == TYPE_CODE_INT
            || type->code () == TYPE_CODE_ENUM
            || type->code () == TYPE_CODE_BOOL
            || type->code () == TYPE_CODE_CHAR
            || type->code () == TYPE_CODE_PTR
            || TYPE_IS_REFERENCE (type))

It might not really be necessary to handle pointer and reference
types if those are always guaranteed to be word sized.  But I
think enum, bool, and char types should be handled.

Also, it would probably be preferable to use reg_size instead
of tdep->wordsize to be consistent.

Finally, there are still white space issues (use tabs instead
of 8 spaces, if there's just a single statement inside an if
it is indented only 2 spaces, not 4).

Bye,
Ulrich


[-- Attachment #2: 0001-Fix-call-functions-command-bug-in-64-bit-programs.patch --]
[-- Type: application/octet-stream, Size: 1483 bytes --]

From d9a8e43d93db669b3f6324549edc7620e6422951 Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Wed, 16 Nov 2022 12:02:38 -0600
Subject: [PATCH] Fix call functions command bug in 64 bits programs for AIX

In AIX for 64 bit programs we need to zero extend variables of integer or enum or char data type.

Otherwise a zero will get dumped in the register as we memset our word to 0 and we copy non zero extended contents to the cache

This patch is a fix for the same.
---
 gdb/rs6000-aix-tdep.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gdb/rs6000-aix-tdep.c b/gdb/rs6000-aix-tdep.c
index d47974b51d1..5e670721d29 100644
--- a/gdb/rs6000-aix-tdep.c
+++ b/gdb/rs6000-aix-tdep.c
@@ -400,7 +400,15 @@ rs6000_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
 	  gdb_byte word[PPC_MAX_REGISTER_SIZE];
 
 	  memset (word, 0, reg_size);
-	  memcpy (word, value_contents (arg).data (), len);
+	  if (type->code () == TYPE_CODE_INT
+	     || type->code () == TYPE_CODE_ENUM
+	     || type->code () == TYPE_CODE_BOOL
+	     || type->code () == TYPE_CODE_CHAR)
+	    /* Sign or zero extend the "int" into a "word".  */
+	    store_unsigned_integer (word, reg_size, byte_order,
+				    unpack_long (type, value_contents (arg).data ()));
+          else
+	    memcpy (word, value_contents (arg).data (), len);
 	  regcache->cooked_write (tdep->ppc_gp0_regnum + 3 +ii, word);
 	}
       ++argno;
-- 
2.31.1

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Tom Tromey]

>> It might not really be necessary to handle pointer and reference
>> types if those are always guaranteed to be word sized.  But I
>> think enum, bool, and char types should be handled.

> You were right. Thank you for pointing out. I have attached the
> outputs below. It works fine now.

I didn't look at this too deeply, but it's worth noting that code
handling the marshalling of integers should also handle
TYPE_CODE_FIXED_POINT as well, as those are integers with a funny
name.  There should be some Ada tests for this.

If you can't test Ada, I guess don't worry about it.  I'm not 100% sure
the way you've written this will work for a fixed-point number.

> 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?

> BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2
> BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b

These seem concerning.

thanks,
Tom

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>You were right. Thank you for pointing out. I have attached
>the outputs below. It works fine now. 

This version is OK, I've checked it in now.

Tom does make very valid points in his reply however,
so it would be good if you can still follow up on that.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Aditya Kamath1]

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

Hi Ulrich,

Thank you for pushing the patch. Sure..

Hi Tom,

>> 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?

>> BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x2
>> BFD: /usr/lib/libc.a(/usr/lib/libc.a(shr_64.o)): wrong auxtype 0xff for storage class 0x6b

>These seem concerning.

I will check why this is happening. I will plan for it in our future patches for AIX and keep you in cc in that mailing thread once I find a solution. By the way I use DWARF for all the tests I do.


>I didn't look at this too deeply, but it's worth noting that code
>handling the marshalling of integers should also handle
>TYPE_CODE_FIXED_POINT as well, as those are integers with a funny
>name.  There should be some Ada tests for this.

>If you can't test Ada, I guess don't worry about it.  I'm not 100% sure
>the way you've written this will work for a fixed-point number.

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.

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. For example, I found how IBM Z folks do it which is in the link [ https://www.ibm.com/docs/en/zos/2.4.0?topic=specifiers-fixed-point-decimal-types-c-only#dcon ]. While few of other platforms that do not have float type use this [ https://www.ibm.com/docs/en/rhapsody/8.4.0?topic=elements-using-fixed-point-variables ].

Kindly let me know if any of you know how we can use it in C/C++ in AIX. I would like to learn and then check how we can handle them in GDB. So far in C or C++ I have not been successful in finding how to use fixed point integers in AIX.

Have a nice day ahead.

Thanks and regards,
Aditya.

Using fixed-point variables<https://www.ibm.com/docs/en/rhapsody/8.4.0?topic=elements-using-fixed-point-variables>
You can use IBM Rational Rhapsody Developer for C to provide an option to use fixed-point variables for target systems that do not include floating-point capabilities.
www.ibm.com

Fixed point decimal types (C only) - IBM<https://www.ibm.com/docs/en/zos/2.4.0?topic=specifiers-fixed-point-decimal-types-c-only#dcon>
Fixed point decimal types are classified as arithmetic types. To declare fixed point decimal variables and initialize them with fixed point decimal constants, you use the type specifier decimal.For this type specifier, decimal is a macro that is defined in the decimal.h header file. Remember to include decimal.h if you use fixed point decimals in your program.
www.ibm.com



________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 17 November 2022 18:24
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; simon.marchi@efficios.com <simon.marchi@efficios.com>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>; tom@tromey.com <tom@tromey.com>; Sanket Rathi <sanrathi@in.ibm.com>
Subject: Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>You were right. Thank you for pointing out. I have attached
>the outputs below. It works fine now.

This version is OK, I've checked it in now.

Tom does make very valid points in his reply however,
so it would be good if you can still follow up on that.

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX

[Tom Tromey]

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

RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

[-- 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 --]

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Tom Tromey]

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

RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

[-- 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

RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

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

Sorry for the previous email. I did not answer Tom’s query on Stabs. Resending the email again with the answer for the same.

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.



>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.

So I have taken this up with my seniors.. They are still required.. Kindly do not depreciate.. As soon as any decision is made to not use stabs and I receive an information on the same,  I will communicate it to the GDB community, you and Ulrich that we can depreciate.. But we need stabs as of now..

Have a nice day ahead.

Thanks and regards,
Aditya.

From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
Date: Monday, 17 April 2023 at 6:38 PM
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: [EXTERNAL] Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning
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

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>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. 

>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. 

Instead of simply disabling generation of those psymtab entries,
I think we should first understand why those values end up wrong.
Is this already a problem in the underlying XCOFF file debug info,
or is this just read in incorrectly by GDB/BFD at some point?

Can you debug a bit more exactly where the wrong values come from?
Is there some AIX tool you can use to look at the XCOFF debug info
directly to compare with what GDB is reading?

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

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

Hi Ulrich, Tom and community,

So here is my further understanding to this.

>Instead of simply disabling generation of those psymtab entries,
>I think we should first understand why those values end up wrong.
>Is this already a problem in the underlying XCOFF file debug info,
>or is this just read in incorrectly by GDB/BFD at some point?

>Can you debug a bit more exactly where the wrong values come from?
>Is there some AIX tool you can use to look at the XCOFF debug info
>directly to compare with what GDB is reading?

Consider the example
1: #include <stdio.h>
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:}

For this code there are 345 symbols I see using the dump -tov ~/gdb_tests/simple_test.. I have pasted them below this email…
All of them are getting into the tables via xcoff_initial_scan code. Their entries are also same as the object dump.

So here is the thing, there are 4 values for which the psymtab entries are created. Their addresses are 0, 1a0, 0 and 8.

In the object dump outputs I see they are like this..
[235]   m   0x00000000     debug     0    gsym                    __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[236]   m   0x00000008     debug     0    gsym                    __exit_funcs:G4
[188]   m   0x000001a0     debug     0     fun                    __internal_atexit:F8=r8;-2147483648;2147483647;
[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:

It looks like these are global symbols and functions. Hence they satisfy the case G in the xcoffread.c file and psymtab entries are created.

Kindly have a look at the disassemble output of this code,
(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>:      warning: (Internal error: pc 0x100005a8 in read in psymtab, but not in symtab.)

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

When we are at line number 4 of the C code and press a next, GDB is searching for the next pc which is 0x100005a8, nothing but in search of printf ().This is done in the function find_pc_sect_line () in symtab.c.

Here pc parameter in the function is 0x100005a8. GDB here figures out this is a shared library trampoline. In gdb terms mst_solib_trampoline.

So it goes in search of find_pc_line (mfunsym.value_address (), 0); Where mfunsym.value_address is d03b0160 which is range of the libc shared library and 0 indicates to not raise a warning.

info sharedlibrary output
(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)

Now, GDB searches for pc d03b0160 again in function find_pc_sect_line () in symtab.c…
This address is not there in object dump output, not there in symbol table and not there in psymbol table as well.

Hence now it goes into “ cust = find_pc_sect_compunit_symtab (pc, section); “ with this pc. This is where the psymtab journey and the mess starts. This function is again in the symtab.c file. It searches throughout the symbol table and does not find the address d03b0160.

Now it gets into this code

/* Not found in symtabs, search the "quick" symtabs (e.g. psymtabs).  */

  for (objfile *objf : current_program_space->objfiles ())
    {
      struct compunit_symtab *result
        = objf->find_pc_sect_compunit_symtab (msymbol, pc, section, 1);
      if (result != NULL)
        return result;
    }

We can see objf->find_pc_sect_compunit_symtab (msymbol, pc, section, 1);, the warnings are turned on now. Through the find_pc_sect_compunit_symtab under the psymtab namespace it goes in search of the best_pc.

The route it takes is psymbol_functions::find_pc_sect_compunit_symtab () -> psymbol_functions::find_pc_sect_psymtab () -> find_pc_sect_psymtab_closer () -> p = find_pc_sect_psymbol (objfile, tpst, pc, section);

So all this is done to find the best nearest pc possible..

Along these lines in find_pc_sect_symbol ()

for (partial_symbol *p : psymtab->global_psymbols)
    {
      if (p->domain == VAR_DOMAIN
          && p->aclass == LOC_BLOCK
          && pc >= p->address (objfile)
          && (p->address (objfile) > best_pc
              || (psymtab->text_low (objfile) == 0
                  && best_pc == 0 && p->address (objfile) == 0)))
        {
          if (section != NULL)  /* Match on a specific section.  */
            {
              if (!matching_obj_sections (p->obj_section (objfile),
                                          section))
                continue;
            }
          best_pc = p->address (objfile);
          best = p;
        }
    }

Over here we know that address 1a0 will be closest to mfunsym.value_address or printf () address d03b0160. Hence this psymtab entry is returned. Although this is far from being close but still turns out to be the best. This makes me confused why we are looking for the best nearest PC here. Shouldn’t this have some limit to the difference in pc’s of what we are looking for??

This is where I feel we need to change our logic.

After this in the psymbol_functions::find_pc_sect_compunit_symtab () since it returned that 1a0’s psymtab entry, the below code does the rest. And AIX GDB is flooded with the warnings.


struct partial_symtab *ps = find_pc_sect_psymtab (objfile,
                                                    pc, section,
                                                    msymbol);
  if (ps != NULL)
    {
      if (warn_if_readin && ps->readin_p (objfile))
        /* Might want to error() here (in case symtab is corrupt and
           will cause a core dump), but maybe we can successfully
           continue, so let's not.  */
        warning (_("\
(Internal error: pc %s in read in psymtab, but not in symtab.)\n"),
                 paddress (objfile->arch (), pc));
      psymtab_to_symtab (objfile, ps);
      return ps->get_compunit_symtab (objfile);
    }

So concluding my explain nation, there are two things.

One is this psymtab entries, we need to limit the difference of pc that can be used as best_pc.. This can be one entry point to take control and add a symbol table for AIX for this printf (). Such that if the limit is too much this might indicate the need for an external shared library symbol and add the symbol entry. I see in dwarf2/read.c there is some code doing the shared library entries if I understood it correctly. But I do not know if this can be the correct way. But I got my previous patch wrong. That I can say for sure. Removing the psymtab entries may not be correct and these entries are what is there in the object dump.

Second thing, we can think is some kind of lazy loading where the moment we detect a shared library trampoline to be executed or will be the PC we can create the symbol table entry for the shared library functions, so that before GDB jumps into of find_pc_line (mfunsym.value_address (), 0), we can add the symbol table entry.

I have not succeeded so far in my attempt to fix this though I learnt different things about symbols and symbol table. I have given the explanation to what I understood and where can be the points we can make changes.

Kindly guide me, so that we can fix this issue for GDB and AIX. I want to know what can we do next from here, given we know what is going on and the root cause and place of problem for the same.

Awaiting a reply.

Have a nice day ahead.

Thanks and regards,
Aditya.

------------------------------------------------------
Object dump output-----
dump -tov ~/gdb_tests/simple_test

/home/aditya/gdb_tests/simple_test:

                        ***Object Module Header***
# Sections      Symbol Ptr      # Symbols       Opt Hdr Len     Flags
        10      0x00002078            345                72     0x1002
Flags=( EXEC DYNLOAD DEP_SYSTEM )
Timestamp = "Apr 21 01:07:51 2023"
Magic = 0x1df  (32-bit XCOFF)

                        ***Optional Header***
Tsize       Dsize       Bsize       Tstart      Dstart
0x00000b6d  0x000001d7  0x00000214  0x10000290  0x20000dfd

SNloader    SNentry     SNtext      SNtoc       SNdata
0x0004      0x0002      0x0001      0x0002      0x0002

TXTalign    DATAalign   TOC         vstamp      entry
0x0005      0x0004      0x20000f5c  0x0001      0x20000f24

maxSTACK    maxDATA     SNbss       magic       modtype
0x00000000  0x00000000  0x0003      0x010b        1L

                        ***Symbol Table Information***
[Index] m        Value       Scn   Aux  Sclass    Type            Name
[Index] a0                                                        Fname
[Index] a1      Tagndx      Lnno  Size  Lnoptr    Endndx
[Index] a2      Tagndx            Fsiz  Lnoptr    Endndx
[Index] a3      Tagndx      Lnno  Size  Dimensions
[Index] a4   CSlen     PARMhsh SNhash SMtype SMclass Stab SNstab
[Index] a5      SECTlen    #RELent    #LINnums

[0]     m   0x00000000     undef     1  extern                    errno
[1]     a4  0x00000000       0    0     ER       RW    0    0
[2]     m   0x00000000     undef     1  extern                    calloc
[3]     a4  0x00000000       0    0     ER       DS    0    0
[4]     m   0x00000000     undef     1  extern                    exit
[5]     a4  0x00000000       0    0     ER       DS    0    0
[6]     m   0x00000000     undef     1  extern                    __assert
[7]     a4  0x00000000       0    0     ER       DS    0    0
[8]     m   0x00000000     undef     1  extern                    puts
[9]     a4  0x00000000       0    0     ER       DS    0    0
[10]    m   0x00000000     undef     1  extern                    __strtollmax
[11]    a4  0x00000000       0    0     ER       DS    0    0
[12]    m   0x00000000     undef     1  extern                    __mod_init
[13]    a4  0x00000000       0    0     ER       DS    0    0
[14]    m   0x00000000     undef     1  extern                    __crt0v
[15]    a4  0x00000000       0    0     ER       RW    0    0
[16]    m   0x00000000     undef     1  extern                    __malloc_user_defined_name
[17]    a4  0x00000000       0    0     ER       RW    0    0
[18]    m   0x20000f5c     .data     1  unamex                    TOC
[19]    a4  0x00000000       0    0     SD      TC0    0    0
[20]    m   0x20000f84     .data     1  unamex                    __crt0v
[21]    a4  0x00000004       0    0     SD       TC    0    0
[22]    m   0x20000f88     .data     1  unamex                    __mod_init
[23]    a4  0x00000004       0    0     SD       TC    0    0
[24]    m   0x20000f8c     .data     1  unamex                    crt0_data
[25]    a4  0x00000004       0    0     SD       TC    0    0
[26]    m   0x20000f90     .data     1  unamex                    __malloc_user_defined_name
[27]    a4  0x00000004       0    0     SD       TC    0    0
[28]    m   0x20000f94     .data     1  unamex                    errno
[29]    a4  0x00000004       0    0     SD       TC    0    0
[30]    m   0x20000f98     .data     1  unamex                    __strtollmax
[31]    a4  0x00000004       0    0     SD       TC    0    0
[32]    m   0x20000f9c     .data     1  unamex                    LC..0
[33]    a4  0x00000004       0    0     SD       TC    0    0
[34]    m   0x20000fa0     .data     1  unamex                    puts
[35]    a4  0x00000004       0    0     SD       TC    0    0
[36]    m   0x20000fa4     .data     1  unamex                    LC..2
[37]    a4  0x00000004       0    0     SD       TC    0    0
[38]    m   0x20000fa8     .data     1  unamex                    exit
[39]    a4  0x00000004       0    0     SD       TC    0    0
[40]    m   0x20000fac     .data     1  unamex                    __dso_handle
[41]    a4  0x00000004       0    0     SD       TC    0    0
[42]    m   0x20000fb0     .data     1  unamex                    __exit_funcs
[43]    a4  0x00000004       0    0     SD       TC    0    0
[44]    m   0x20000fb4     .data     1  unamex                    LANCHOR..0
[45]    a4  0x00000004       0    0     SD       TC    0    0
[46]    m   0x20000fb8     .data     1  unamex                    calloc
[47]    a4  0x00000004       0    0     SD       TC    0    0
[48]    m   0x20000fbc     .data     1  unamex                    LANCHOR..1
[49]    a4  0x00000004       0    0     SD       TC    0    0
[50]    m   0x20000fc0     .data     1  unamex                    __assert
[51]    a4  0x00000004       0    0     SD       TC    0    0
[52]    m   0x20000fc4     .data     1  unamex                    __new_exitfn_called
[53]    a4  0x00000004       0    0     SD       TC    0    0
[54]    m   0x20000fc8     .data     1  unamex                    count
[55]    a4  0x00000004       0    0     SD       TC    0    0
[56]    m   0x20000fcc     .data     1  unamex                    dtors.0
[57]    a4  0x00000004       0    0     SD       TC    0    0
[58]    m   0x20000fd0     .data     1  unamex                    dtors.0.P4
[59]    a4  0x00000004       0    0     SD       TC    0    0
[60]    m   0x0000003d     debug     0    FILE      FRONT:COM
[61]    m   0x00000052     debug     0    FILE        ASM:COM     crt0main.s
[62]    m   0x10000290     .text     1  unamex                    .__start
[63]    a4  0x000000a5       0    0     SD       PR    0    0
[64]    m   0x10000290     .text     1  extern                    .__start
[65]    a4  0x0000003e       0    0     LD       PR    0    0
[66]    m   0x20000f24     .data     1  extern                    __start
[67]    a4  0x00000008       0    0     SD       DS    0    0
[68]    m   0x20000e00     .data     1  unamex                    crt0_data
[69]    a4  0x0000002c       0    0     SD       RW    0    0
[70]    m   0x20000f60     .data     1  extern                    p_xargc
[71]    a4  0x00000004       0    0     CM       TD    0    0
[72]    m   0x20000f78     .data     1  extern                    p_xargv
[73]    a4  0x00000004       0    0     CM       TD    0    0
[74]    m   0x20000f7c     .data     1  extern                    p_xrcfg
[75]    a4  0x00000004       0    0     CM       TD    0    0
[76]    m   0x20000f80     .data     1  extern                    p_xrc
[77]    a4  0x00000004       0    0     CM       TD    0    0
[78]    m   0x20000f5c     .data     1  extern                    _malloc_user_defined_name
[79]    a4  0x00000004       0    0     CM       TD    0    0
[80]    m   0x200011e4      .bss     1  extern                    __C_runtime_pstartup
[81]    a4  0x00000004       0    0     CM       RW    0    0
[82]    m   0x0000006a     debug     3    FILE          C:COM     .file
[83]    a0                                                        ../../../../../../../src/bos/usr/ccs/lib/libc/__threads_init.c
[84]    a0                                                        Tue May  7 10:49:34 2019
[85]    a0                                                        IBM XL C for AIX, Version 13.1.0.2
[86]    m   0x10000340     .text     1  unamex                    **No Symbol**
[87]    a4  0x00000160       0    0     SD       PR    0    0
[88]    m   0x10000340     .text     1  extern                    .__threads_init
[89]    a4  0x00000056       0    0     LD       PR    0    0
[90]    m   0x10000380     .text     1  unamex                    .__threads_init@AF2_1<mailto:.__threads_init@AF2_1>
[91]    a4  0x00000056       0    0     LD       PR    0    0
[92]    m   0x20000e30     .data     1  unamex                    _$STATIC
[93]    a4  0x00000059       0    0     SD       RW    0    0
[94]    m   0x20000f2c     .data     1  extern                    __threads_init
[95]    a4  0x0000000c       0    0     SD       DS    0    0
[96]    m   0x20000f64     .data     1  extern                    __pth_init_routine
[97]    a4  0x00000004       0    0     CM       TD    0    0
[98]    m   0x20000f68     .data     1  extern                    _bsd_init_routine
[99]    a4  0x00000004       0    0     CM       TD    0    0
[100]   m   0x20000f6c     .data     1  extern                    _xti_tli_init_routine
[101]   a4  0x00000004       0    0     CM       TD    0    0
[102]   m   0x20000f70     .data     1  extern                    _nsl_init_routine
[103]   a4  0x00000004       0    0     CM       TD    0    0
[104]   m   0x20000f74     .data     1  extern                    __dce_compat_init_routine
[105]   a4  0x00000004       0    0     CM       TD    0    0
[106]   m   0x0000007d     debug     0    FILE          C:COM     /tmp//ccxFwDye.cdtor.c
[107]   m   0x10000ad4     .text     1  unamex                    .text
[108]   a4  0x00000124       0    0     SD       PR    0    0
[109]   m   0x10000ad4     .text     1  extern                    ._GLOBAL__FI_simple_test
[110]   a4  0x0000006b       0    0     LD       PR    0    0
[111]   m   0x10000b30     .text     1  extern                    ._GLOBAL__FD_simple_test
[112]   a4  0x0000006b       0    0     LD       PR    0    0
[113]   m   0x20000f44     .data     1  unamex                    _GLOBAL__FI_simple_test
[114]   a4  0x0000000c       0    0     SD       DS    0    0
[115]   m   0x20000f44     .data     1  extern                    _GLOBAL__FI_simple_test
[116]   a4  0x00000071       0    0     LD       DS    0    0
[117]   m   0x20000f50     .data     1  unamex                    _GLOBAL__FD_simple_test
[118]   a4  0x0000000c       0    0     SD       DS    0    0
[119]   m   0x20000f50     .data     1  extern                    _GLOBAL__FD_simple_test
[120]   a4  0x00000075       0    0     LD       DS    0    0
[121]   m   0x20000eb0     .data     1  unamex                    _ccxFwDyecdtor.rw_
[122]   a4  0x00000004       0    0     SD       RW    0    0
[123]   m   0x200011e0      .bss     1  unamex                    _ccxFwDyecdtor.bss_
[124]   a4  0x00000004       0    0     CM       BS    0    0
[125]   m   0x0000008e     debug     0    FILE          C:COM     ../../../gcc-10.3.0/libgcc/config/rs6000/crtcxa.c
[126]   m   0x1000062c     .text     1  unamex                    .text
[127]   a4  0x00000000       0    0     SD       PR    0    0
[128]   m   0x100005f8     .text     1  unamex                    ..text.exit
[129]   a4  0x00000034       0    0     SD       PR    0    0
[130]   m   0x100005f8     .text     1  extern                    .__init_aix_libgcc_cxa_atexit
[131]   a4  0x00000080       0    0     LD       PR    0    0
[132]   m   0x10000628     .text     1  extern                    ._GLOBAL__D_65535_0___dso_handle
[133]   a4  0x00000080       0    0     LD       PR    0    0
[134]   m   0x20000e90     .data     1  unamex                    .data
[135]   a4  0x00000008       0    0     SD       RW    0    0
[136]   m   0x20000e90     .data     1  extern                    __dso_handle
[137]   a4  0x00000086       0    0     LD       RW    0    0
[138]   m   0x20000f38     .data     1  unamex                    _GLOBAL__D_65535_0___dso_handle
[139]   a4  0x0000000c       0    0     SD       DS    0    0
[140]   m   0x20000f38     .data     1  extern                    _GLOBAL__D_65535_0___dso_handle
[141]   a4  0x0000008a       0    0     LD       DS    0    0
[142]   m   0x000000a3     debug     0    FILE          C:COM     /home/aditya/gdb_tests/simple_test.c
[143]   m   0x00000000   .dwline     1   dwarf                    .dwline
[144]   a5  0x00000118     0x0000
[145]   m   0x00000000   .dwinfo     1   dwarf                    .dwinfo
[146]   a5  0x00000223     0x0000
[147]   m   0x00000000  .dwabrev     1   dwarf                    .dwabrev
[148]   a5  0x000000b2     0x0000
[149]   m   0x00000000  .dwarnge     1   dwarf                    .dwarnge
[150]   a5  0x00000020     0x0000
[151]   m   0x00000000    .dwloc     1   dwarf                    .dwloc
[152]   a5  0x00000074     0x0000
[153]   m   0x100004a0     .text     1  unamex                    .text
[154]   a4  0x000000e0       0    0     SD       PR    0    0
[155]   m   0x100004a0     .text     2  unamex                    .strtoimax
[156]   a2           0             224    7658     135
[157]   a4  0x00000099       0    0     LD       PR    0    0
[158]   m   0x10000518     .text     2  extern                    .main
[159]   a2           0             224    7664     135
[160]   a4  0x00000099       0    0     LD       PR    0    0
[161]   m   0x10000c00     .text     1  unamex                    _simpletest.rop_
[162]   a4  0x00000029       0    0     SD       RO    0    0
[163]   m   0x000000fb     debug     0    FILE          C:PPC     ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[164]   m   0x00001f76     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[165]   m   0x00001f76     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[166]   m   0x00001f82     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[167]   m   0x00001f82     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[168]   m   0x00001f8e     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[169]   m   0x00001fbe     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[170]   m   0x00001fca     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[171]   m   0x00001fca     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_atexit.c
[172]   m   0x100007a8     .text     1  unamex                    .text
[173]   a4  0x000002dc       0    0     SD       PR    0    0
[174]   m   0x100007a8     .text     2  extern                    .__new_exitfn
[175]   a2           0             416    7670     185
[176]   a4  0x000000ac       0    0     LD       PR    0    0
[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:
[178]   m   0x100007a8     .text     1     fcn                    .bf
[179]   a1           0        75     0       0       0
[180]   m   0x0000001f     debug     0   rpsym                    listp:R3=*4=*5=xsexit_function_list:
[181]   m   0x00000003     debug     0    rsym                    r:r1
[182]   m   0x00000009     debug     0    rsym                    i:r6=7=r7;0;037777777777;
[183]   m   0x10000924     .text     1     fcn                    .ef
[184]   a1           0       131     0       0       0
[185]   m   0x10000948     .text     2  extern                    .__internal_atexit
[186]   a2           0             156    7952     197
[187]   a4  0x000000ac       0    0     LD       PR    0    0
[188]   m   0x000001a0     debug     0     fun                    __internal_atexit:F8=r8;-2147483648;2147483647;
[189]   m   0x10000948     .text     1     fcn                    .bf
[190]   a1           0        40     0       0       0
[191]   m   0x0000001d     debug     0   rpsym                    func:R9=*10=f11=11
[192]   m   0x0000001e     debug     0   rpsym                    arg:R12=*11
[193]   m   0x0000001f     debug     0   rpsym                    d:R12
[194]   m   0x00000006     debug     0   rpsym                    listp:R3
[195]   m   0x100009bc     .text     1     fcn                    .ef
[196]   a1           0        55     0       0       0
[197]   m   0x100009e8     .text     2  extern                    .__cxa_atexit
[198]   a2           0             156    8042     235
[199]   a4  0x000000ac       0    0     LD       PR    0    0
[200]   m   0x100009e8     .text     1     fcn                    .bf
[201]   a1           0        63     0       0       0
[202]   m   0x0000001d     debug     0   rpsym                    func:R9
[203]   m   0x0000001e     debug     0   rpsym                    arg:R12
[204]   m   0x0000001f     debug     0   rpsym                    d:R12
[205]   m   0x100009f0     .text     1   block                    .bb
[206]   a1           0         1     0       0      53
[207]   m   0x100009f4     .text     1   block                    .eb
[208]   a1           0        63     0       0       0
[209]   m   0x10000a08     .text     1   block                    .bb
[210]   a1           0         1     0       0      61
[211]   m   0x10000a08     .text     1   block                    .bb
[212]   a1           0         1     0       0      59
[213]   m   0x10000a0c     .text     1   block                    .eb
[214]   a1           0        63     0       0       0
[215]   m   0x10000a0c     .text     1   block                    .eb
[216]   a1           0        63     0       0       0
[217]   m   0x10000a14     .text     1   block                    .bb
[218]   a1           0         1     0       0      69
[219]   m   0x10000a14     .text     1   block                    .bb
[220]   a1           0         1     0       0      67
[221]   m   0x10000a3c     .text     1   block                    .eb
[222]   a1           0        63     0       0       0
[223]   m   0x10000a3c     .text     1   block                    .eb
[224]   a1           0        63     0       0       0
[225]   m   0x10000a58     .text     1   block                    .bb
[226]   a1           0         3     0       0      77
[227]   m   0x10000a58     .text     1   block                    .bb
[228]   a1           0         3     0       0      75
[229]   m   0x10000a5c     .text     1   block                    .eb
[230]   a1           0        65     0       0       0
[231]   m   0x10000a5c     .text     1   block                    .eb
[232]   a1           0        65     0       0       0
[233]   m   0x10000a60     .text     1     fcn                    .ef
[234]   a1           0        65     0       0       0
[235]   m   0x00000000     debug     0    gsym                    __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[236]   m   0x00000008     debug     0    gsym                    __exit_funcs:G4
[237]   m   0x10000dc0     .text     1  unamex                    _cxaatexit.rop_
[238]   a4  0x0000003d       0    0     SD       RO    0    0
[239]   m   0x10000cb0     .text     1  unamex                    _cxaatexit.ro_
[240]   a4  0x00000104       0    0     SD       RO    0    0
[241]   m   0x10000cb0     .text     1  extern                    _GLOBAL__F___internal_atexit
[242]   a4  0x000000ef       0    0     LD       RO    0    0
[243]   m   0x20000ea0     .data     1  unamex                    .data
[244]   a4  0x00000010       0    0     SD       RW    0    0
[245]   m   0x20000ea0     .data     1  extern                    __new_exitfn_called
[246]   a4  0x000000f3       0    0     LD       RW    0    0
[247]   m   0x20000ea8     .data     1  extern                    __exit_funcs
[248]   a4  0x000000f3       0    0     LD       RW    0    0
[249]   m   0x20000fd8      .bss     1  unamex                    _cxaatexit.bss_3_
[250]   a4  0x00000208       0    0     CM       BS    0    0
[251]   m   0x00000140     debug     0    FILE          C:PPC     ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[252]   m   0x00001fe2     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[253]   m   0x00001fe2     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[254]   m   0x00002048     debug     0   bincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[255]   m   0x00002048     debug     0   eincl                    ../../../gcc-10.3.0/libgcc/config/rs6000/cxa_finalize.c
[256]   m   0x1000062c     .text     1  unamex                    .text
[257]   a4  0x0000017c       0    0     SD       PR    0    0
[258]   m   0x1000062c     .text     2  extern                    .__cxa_finalize
[259]   a2           0             380    8150     316
[260]   a4  0x00000100       0    0     LD       PR    0    0
[261]   m   0x1000062c     .text     1     fcn                    .bf
[262]   a1           0        44     0       0       0
[263]   m   0x0000001b     debug     0   rpsym                    d:R1=*2=2
[264]   m   0x0000001a     debug     0    rsym                    funcs:r3=*4=xsexit_function_list:
[265]   m   0x0000001f     debug     0    rsym                    f:r5=*6=xsexit_function:
[266]   m   0x10000660     .text     1   block                    .bb
[267]   a1           0         1     0       0      34
[268]   m   0x00000009     debug     0    rsym                    cxafn:r7=*8=f2
[269]   m   0x00000003     debug     0    rsym                    cxaarg:r1
[270]   m   0x10000660     .text     1   block                    .bb
[271]   a1           0         1     0       0      32
[272]   m   0x10000660     .text     1   block                    .bb
[273]   a1           0         1     0       0      30
[274]   m   0x10000664     .text     1   block                    .eb
[275]   a1           0        44     0       0       0
[276]   m   0x10000664     .text     1   block                    .eb
[277]   a1           0        44     0       0       0
[278]   m   0x10000664     .text     1   block                    .eb
[279]   a1           0        44     0       0       0
[280]   m   0x10000688     .text     1   block                    .bb
[281]   a1           0         5     0       0      45
[282]   m   0x0000001f     debug     0    rsym                    f:r5
[283]   m   0x100006ac     .text     1   block                    .bb
[284]   a1           0         9     0       0      43
[285]   m   0x00000009     debug     0    rsym                    cxafn:r7
[286]   m   0x00000003     debug     0    rsym                    cxaarg:r1
[287]   m   0x100006bc     .text     1   block                    .eb
[288]   a1           0        14     0       0       0
[289]   m   0x100006c8     .text     1   block                    .eb
[290]   a1           0        14     0       0       0
[291]   m   0x1000071c     .text     1   block                    .bb
[292]   a1           0        42     0       0      68
[293]   m   0x0000001f     debug     0    rsym                    f:r5
[294]   m   0x1000071c     .text     1   block                    .bb
[295]   a1           0        42     0       0      66
[296]   m   0x00000009     debug     0    rsym                    cxafn:r7
[297]   m   0x00000003     debug     0    rsym                    cxaarg:r1
[298]   m   0x10000724     .text     1   block                    .bb
[299]   a1           0        17     0       0      60
[300]   m   0x10000724     .text     1   block                    .bb
[301]   a1           0        17     0       0      58
[302]   m   0x1000073c     .text     1   block                    .eb
[303]   a1           0        60     0       0       0
[304]   m   0x1000073c     .text     1   block                    .eb
[305]   a1           0        60     0       0       0
[306]   m   0x10000740     .text     1   block                    .bb
[307]   a1           0        16     0       0      64
[308]   m   0x10000784     .text     1   block                    .eb
[309]   a1           0        30     0       0       0
[310]   m   0x10000784     .text     1   block                    .eb
[311]   a1           0        30     0       0       0
[312]   m   0x10000784     .text     1   block                    .eb
[313]   a1           0        30     0       0       0
[314]   m   0x10000784     .text     1     fcn                    .ef
[315]   a1           0        85     0       0       0
[316]   m   0x10000c30     .text     1  unamex                    _cxafinalize.ro_
[317]   a4  0x00000080       0    0     SD       RO    0    0
[318]   m   0x10000c30     .text     1  extern                    _GLOBAL__F___cxa_finalize
[319]   a4  0x0000013c       0    0     LD       RO    0    0
[320]   m   0x00000145     debug     0    FILE        ASM:COM     glink.s
[321]   m   0x100005d0     .text     1  unamex                    .exit
[322]   a4  0x00000028       0    0     SD       GL    0    0
[323]   m   0x100005d0     .text     1  extern                    .exit
[324]   a4  0x00000141       0    0     LD       GL    0    0
[325]   m   0x0000014a     debug     0    FILE        ASM:COM     glink.s
[326]   m   0x10000580     .text     1  unamex                    .__strtollmax
[327]   a4  0x00000028       0    0     SD       GL    0    0
[328]   m   0x10000580     .text     1  extern                    .__strtollmax
[329]   a4  0x00000146       0    0     LD       GL    0    0
[330]   m   0x0000014f     debug     0    FILE        ASM:COM     glink.s
[331]   m   0x100005a8     .text     1  unamex                    .puts
[332]   a4  0x00000028       0    0     SD       GL    0    0
[333]   m   0x100005a8     .text     1  extern                    .puts
[334]   a4  0x0000014b       0    0     LD       GL    0    0
[335]   m   0x00000154     debug     0    FILE        ASM:COM     glink.s
[336]   m   0x10000a84     .text     1  unamex                    .calloc
[337]   a4  0x00000028       0    0     SD       GL    0    0
[338]   m   0x10000a84     .text     1  extern                    .calloc
[339]   a4  0x00000150       0    0     LD       GL    0    0
[340]   m   0xffffffff     debug     0    FILE        ASM:COM     glink.s
[341]   m   0x10000aac     .text     1  unamex                    .__assert
[342]   a4  0x00000028       0    0     SD       GL    0    0
[343]   m   0x10000aac     .text     1  extern                    .__assert
[344]   a4  0x00000155       0    0     LD       GL    0    0


From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Tuesday, 18 April 2023 at 3:42 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Aditya Kamath1 <Aditya.Kamath1@ibm.com>, tom@tromey.com <tom@tromey.com>
Cc: 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
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>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.

>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.

Instead of simply disabling generation of those psymtab entries,
I think we should first understand why those values end up wrong.
Is this already a problem in the underlying XCOFF file debug info,
or is this just read in incorrectly by GDB/BFD at some point?

Can you debug a bit more exactly where the wrong values come from?
Is there some AIX tool you can use to look at the XCOFF debug info
directly to compare with what GDB is reading?

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>So here is the thing, there are 4 values for which the psymtab entries are created. Their addresses are 0, 1a0, 0 and 8. 
>
>In the object dump outputs I see they are like this.. 
>[235]   m   0x00000000     debug     0    gsym                    __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
>[236]   m   0x00000008     debug     0    gsym                    __exit_funcs:G4
>[188]   m   0x000001a0     debug     0     fun                    __internal_atexit:F8=r8;-2147483648;2147483647;
>[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:

It seems to be these numbers are not actual addresses,
which looks like the root cause of the problem.

In fact, looking e.g. at "__new_exitfn" in the detailed dump below:

>[174]   m   0x100007a8     .text     2  extern                    .__new_exitfn
>[175]   a2           0             416    7670     185           
>[176]   a4  0x000000ac       0    0     LD       PR    0    0
>[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:
>[178]   m   0x100007a8     .text     1     fcn                    .bf
>[179]   a1           0        75     0       0       0           
>[180]   m   0x0000001f     debug     0   rpsym                    listp:R3=*4=*5=xsexit_function_list:
>[181]   m   0x00000003     debug     0    rsym                    r:r1
>[182]   m   0x00000009     debug     0    rsym                    i:r6=7=r7;0;037777777777;
>[183]   m   0x10000924     .text     1     fcn                    .ef
>[184]   a1           0       131     0       0       0           

We see that there is an actual symbol (in the .text section)
at address 0x100007a8, covering 416 byte (until 0x10000948).

*In addition*, there is a "debug" (stabs) symbol giving the
type of that function.  This also has an address field, but
this is simply zero.

My understanding, and that is apparently confirmed by the
text in the GNU stabs documentation here:
https://sourceware.org/gdb/download/onlinedocs/stabs/Transformations-On-Global-Variables.html
is that the "address" value in the debug entry is not used,
but the actual address should be taken from the .text entry.

Now I'm not sure why this doesn't work correctly, but this
may be a place to investigate further.

(One interesting thing to note is that the names do not match
exactly, as the .text entry has the leading '.' that is used
on ppc64 ... maybe this throws off some of the stabs logic?)

Bye,
Ulrich

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

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

Hi Ulrich, Tom and community,

>My understanding, and that is apparently confirmed by the
>text in the GNU stabs documentation here:
>https://sourceware.org/gdb/download/onlinedocs/stabs/Transformations-On-Global-Variables.html
>is that the "address" va lue in the debug entry is not used,
>but the actual address should be taken from the .text entry.

>Now I'm not sure why this doesn't work correctly, but this
>may be a place to investigate further.

>(One interesting thing to note is that the names do not match
>exactly, as the .text entry has the leading '.' that is used
>on ppc64 ... maybe this throws off some of the stabs logic?)

Thank you so much for this explanation. So here is our investigation further.

This __new_exitfn is coming from libgcc. Libgcc is -g compiled with stabs debugging format.

bash-5.1$ dump -tov /opt/freeware/lib/libgcc_s.a | grep __new_exitfn
[32]    m   0x200007e8     .data     1  unamex                    __new_exitfn_called
[8978]  m   0x100002cc     .text     2  extern                    .__new_exitfn
[8981]  m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:
[9039]  m   0x00000000     debug     0    gsym                    __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
[9053]  m   0x20000060     .data     1  extern                    __new_exitfn_called

We see that gcc 10 has this debug symbol which is copied in every binary compiled with gcc 10.

But if I use gcc 11 whose debug format  is dwarf and -g compiled this symbol is as below. And I do not see that bug anymore.

dump -tov /opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/11/libgcc_s.a | grep __new_exitfn
[32]    m   0x200007d8     .data     1  unamex                    __new_exitfn_called
[2813]  m   0x100003e4     .text     2  extern                    .__new_exitfn
[2834]  m   0x20000050     .data     1  extern                    __new_exitfn_called


So folks who will use this version of gcc will not face this problem.

So this looks like a gcc problem..

From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Monday, 24 April 2023 at 9:14 PM
To: gdb-patches@sourceware.org <gdb-patches@sourceware.org>, Aditya Kamath1 <Aditya.Kamath1@ibm.com>, tom@tromey.com <tom@tromey.com>
Cc: 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
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>So here is the thing, there are 4 values for which the psymtab entries are created. Their addresses are 0, 1a0, 0 and 8.
>
>In the object dump outputs I see they are like this..
>[235]   m   0x00000000     debug     0    gsym                    __new_exitfn_called:G13=14=@s64;r14;0;01777777777777777777777;
>[236]   m   0x00000008     debug     0    gsym                    __exit_funcs:G4
>[188]   m   0x000001a0     debug     0     fun                    __internal_atexit:F8=r8;-2147483648;2147483647;
>[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:

It seems to be these numbers are not actual addresses,
which looks like the root cause of the problem.

In fact, looking e.g. at "__new_exitfn" in the detailed dump below:

>[174]   m   0x100007a8     .text     2  extern                    .__new_exitfn
>[175]   a2           0             416    7670     185
>[176]   a4  0x000000ac       0    0     LD       PR    0    0
>[177]   m   0x00000000     debug     0     fun                    __new_exitfn:F1=*2=xsexit_function:
>[178]   m   0x100007a8     .text     1     fcn                    .bf
>[179]   a1           0        75     0       0       0
>[180]   m   0x0000001f     debug     0   rpsym                    listp:R3=*4=*5=xsexit_function_list:
>[181]   m   0x00000003     debug     0    rsym                    r:r1
>[182]   m   0x00000009     debug     0    rsym                    i:r6=7=r7;0;037777777777;
>[183]   m   0x10000924     .text     1     fcn                    .ef
>[184]   a1           0       131     0       0       0

We see that there is an actual symbol (in the .text section)
at address 0x100007a8, covering 416 byte (until 0x10000948).

*In addition*, there is a "debug" (stabs) symbol giving the
type of that function.  This also has an address field, but
this is simply zero.

My understanding, and that is apparently confirmed by the
text in the GNU stabs documentation here:
https://sourceware.org/gdb/download/onlinedocs/stabs/Transformations-On-Global-Variables.html
is that the "address" value in the debug entry is not used,
but the actual address should be taken from the .text entry.

Now I'm not sure why this doesn't work correctly, but this
may be a place to investigate further.

(One interesting thing to note is that the names do not match
exactly, as the .text entry has the leading '.' that is used
on ppc64 ... maybe this throws off some of the stabs logic?)

Bye,
Ulrich

RE: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Aditya Kamath1]

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

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

Re: [PATCH] Fix call functions command bug in 64-bit programs for AIX and PC read in psymtab-symtab warning

[Ulrich Weigand]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>We see that gcc 10 has this debug symbol which is copied in every binary compiled with gcc 10.
> 
>But if I use gcc 11 whose debug format  is dwarf and -g compiled this symbol is as below. And I do not see that bug anymore. 

Well, that's not surprising given that the bug was in the
GDB stabs handling code - if you don't use stabs you of
course won't see the bug.

>So this looks like a gcc problem..

I don't see how this is a GCC problem?  The stabs code
emitted by GCC seems fine according to the specs, it's
GDB that isn't handling it correctly.

Bye,
Ulrich