Hi Ulrich and Simon,

Here is my answer to our questions for the discussion. Let me know your thoughts.

>The existing code does this:
>      if (!ARCH64 ())
>        *addr = rs6000_ptrace32 (PT_READ_GPR, pid, (int *) nr, 0, 0);
>So a 64-bit GDB debugging a 32-bit inferior, before this patch, would go
>into rs6000_ptrace32, which has:
>#ifdef HAVE_PTRACE64
>   int ret = ptrace64 (req, id, (uintptr_t) addr, data, buf);
>  #else
>    int ret = ptrace (req, id, (int *)addr, data, buf);
>  #endif
>So today it would get PT_READ_GPR using ptrace64, right?  Does it
>already fail today?

>It would be clear that up first.  We don't want this patch to mix
>removing legacy code and bug fixing.

>Note that while it uses ptrace64 in both cases, it uses it differently.
>When reading a GPR from a 64-bit process, the output is through an
>8-byte buffer passed as an out parameter (the 5th parameter).  When
>reading a GPR from a 32-bit process, the output is the return value.

>For the record, I asked Claude to test ptrace64 against both a 64-bit
>and a 32-bit debuggee, and it appears to work in both cases.  But this
>is on AIX 7.3 (7300-01-02-2320), so maybe the behavior is different on
>7.2.

I checked this on both AIX 7.2 and AIX 7.3. PT_READ_GPR, PT_READ_FPR, PT_WRITE_GPR and PT_WRITE_FPR all work correctly when a 32-bit inferior is attached to a 64-bit GDB using ptrace64. I did not observe any EIO failures.


I also discussed the documentation with the AIX kernel maintainers. They clarified that the documented EIO behaviour only applies to certain memory-access and breakpoint-related ptrace operations when using a genuine 64-bit address (addrhi != 0). It does not apply to the GPR/FPR operations above. They also mentioned that the documentation will be updated accordingly.


Based on these findings, we can continue using ptrace64 for both 32-bit and 64-bit inferiors. The assumptions behind my current four patches are therefore no longer valid, and I will rework the series accordingly. While looking through the code I also noticed a fair amount of redundant logic in both aix-thread.c and rs6000-aix-nat.c. Would you prefer that I first complete the cleanup work and then submit any refactoring separately, or would it be reasonable to combine some of those simplifications as part of this effort?

>> When I built GDB as a 64 bit AIX application [Using ptrace () for 32 bit inferior debugee]
>>  to just test, linking fails with:
>>
>> CXXLD  gdb
>>   ld: 0711-317 ERROR: Undefined symbol: .ptrace
>>   ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
>>   collect2: error: ld returned 8 exit status
>>   gmake[2]: *** [Makefile:2367: gdb] Error 1
>>It's strange that this happens, since the doc clearly states that you
>>can use ptrace in 64-bit applications.


On my systems, both ptrace() and ptracex() are unavailable when linking a 64-bit GDB build.


It is mentioned like this in document


The ptrace and ptracex subroutines are not supported in 64-bit mode.


https://www.ibm.com/docs/en/aix/7.2.0?topic=p-ptrace-ptracex-ptrace64-subroutine

>>                 === gdb Summary ===
>>
>> # of unexpected core files      1
>> # of expected passes            41796
>> # of unexpected failures        2346
>> # of unexpected successes       1
>> # of expected failures          17
>> # of known failures             30
>> # of unresolved testcases       31
>> # of untested testcases         105
>> # of unsupported tests          179
>> # of paths in test names        7
>> # of duplicate test names       2

>Not sure what to think of those test results, it seems like some numbers
>got worse.  Are you sure the 64 and 32 bit summaries are not swapped in
>one of those?

Yes, the numbers are correct.

Have a nice day ahead.

Thanks and regards,
Aditya.