Re: ppc32 debugging ppc64, part 1

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Mon, 12 Sep 2005 05:50:47 -0700
> From: Richard Henderson <rth@twiddle.net>
> 
> This is just enough modifications to not immediately fail 
> debugging a 64-bit process from a 32-bit debugger.
> 
> We don't get very far in the actual debugging:
> 
> (gdb) b main
> warning: Breakpoint address adjusted from 0x10093aa0 to 0x10000370.
> Breakpoint 1 at 0x10000370
> (gdb) run
> Starting program: /home/rth/work/gcc/bld-binu64/gdb/z
> warning: Breakpoint address adjusted from 0x10093a40 to 0x100001c0.
> warning: Breakpoint 1 address previously adjusted from 0x10093aa0 to 0x10000370.
> Breakpoint 1, 0x0000000010000370 in ?? ()
> (gdb) ppc
> 0x10000370 <__libc_tsd_CTYPE_B+268436264>:      std     r31,-8(r1)
> 
> But this is better than the original:
> 
> Starting program: /home/rth/work/gcc/bld-binu64/gdb/z
> warning: Breakpoint address adjusted from 0x10093a40 to 0x100001c0.
> Failed to read a valid object file image from memory.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x100001c00002d932 in ?? ()
> 
> 
> Comments?

Hmm, this is really odd.  From what I see above and the changes to the
code you made, the implementation of ptrace seems to be just plain
broken, either in the kernel or in glibc, probably both.

Anyway, I'd really like to see people moving away from using
PTRACE_XFER_TYPE and PTRACE_ARG3_TYPE in favour of PTRACE_TYPE_RET and
PTRACE_TYPE_ARG3.  I wouldn't be surprised if it became clear what's
wrong with ptrace(2) on Linux ppc if you realize that PTRACE_XFER_TYPE
really is the return type of ptrace(2).

This code really should be using PTRACE_GETREGS and friends (like you
indicate in the patch) but those are not implemented I assume?

I'd really wish this would be fixed in the kernel, instead of being
worked around in GDB :-(.

Mark