Re: ppc32 debugging ppc64, part 1

[Daniel Jacobowitz <drow@false.org>]

On Mon, Sep 12, 2005 at 09:47:29PM +0200, Mark Kettenis wrote:
> 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, you seem to be very big on assuming GNU/Linux systems are broken;
I'm sensing a real recurring theme here.  Could you explain exactly
what it is that you think is broken now?

Richard's trying to do something fairly different from GDB's ordinary
usage model of ptrace here.  PTRACE_PEEKDATA_3264 allows a 32-bit
process to request four bytes of memory from the inferior by specifying
a full 64-bit address.  If I'm reading it right, it does this by
passing the address by reference, instead of in arg3.  Similarly
there's a way to read the 64-bit registers in two different 32-bit
pieces.

Hmm, this is a much cleaner way than I'd been using for MIPS n32.  That
bears some thinking about.

-- 
Daniel Jacobowitz
CodeSourcery, LLC