Re: [PATCH] Modify align-c/align-c++ test case for AIX

[Aditya Kamath1 <Aditya.Kamath1@ibm.com>]

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

Hi Ulrich, Tom and community,

>I don't think the problem is the ptrace call itself, it looks
>more like that the *address* is incorrect.

>It would be good to understand a bit better why this is happening.
>I thought on AIX global variables should reside in the TOC section,
>so I thought we should be able to get their address ...

>Can you look into more detail how the address of the
>global_variable symbol is being determined, and why
>we end up with an invalid value (0xffffffff)?

So my understanding is as follows. When we run the p global_variable command we call functions in the order print_command-> print_command_1-> print_value-> value::record_latest-> value::fetch_lazy-> value::fetch_lazy_memory-> read_value_memory…

In read_value_memory () we call target_xfer_partial() where we come rs6000-aix-target’s xfer partial. Since the read_buf value is set we call the ptrace call

buffer.word = rs6000_ptrace32 (PT_READ_I, pid,
                                             (int *)(uintptr_t)rounded_offset,
                                             0, NULL);

This set errno to 5.

Then the following value is returned.
if (errno)
              return TARGET_XFER_EOF;

Then we go to read_value_memory () where these lines execute
else if (status == TARGET_XFER_EOF)
        memory_error (TARGET_XFER_E_IO, memaddr + xfered_total);

In memory_error () we hit err=TARGET_XFER_E_IO in the switch case and print cannot access memory at 0xffffff.

>why
>we end up with an invalid value (0xffffffff)?

After we come out of xfer_partial from rs6000-aix-nat.c in read_value_memory () since we got TARGET_XFER_EOF so it executes

“else if (status == TARGET_XFER_EOF)
        memory_error (TARGET_XFER_E_IO, memaddr + xfered_total);”

This ( memaddr + xfered_total ) is responsible for it. Memaddr was 18446744073709551615. This is itself FFFFFFFFFFFFFFFF.

This got assigned at CORE_ADDR addr = address (); in value::fetch_lazy_memory ()..

In the CORE_ADDR
value::address ()

the return value
is m_location.address + m_offset = -1 and that is 0xffffff in 2’s complement.

So this is what is happening.

Kindly let me know what you think about this and also about the fix I suggested to the align test case with the patch attached in the previous email sent by me.

Thanks and regards,
Aditya.


From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Date: Monday, 13 March 2023 at 7:40 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>
Subject: Re: [PATCH] Modify align-c/align-c++ test case for AIX
Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>(gdb) p global_variable
>ret = -1
>ret = -1
>Cannot access memory at address 0xffffffff
>
>This ret = -1 is a printf(“ret = %d\n”, ret) statement I have
>used within my rs6000-aix-nat.c code to check what my ptrace call returns..

I don't think the problem is the ptrace call itself, it looks
more like that the *address* is incorrect.

It would be good to understand a bit better why this is happening.
I thought on AIX global variables should reside in the TOC section,
so I thought we should be able to get their address ...

Can you look into more detail how the address of the
global_variable symbol is being determined, and why
we end up with an invalid value (0xffffffff)?


Bye,
Ulrich