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

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