ppc32 debugging ppc64, part 1

[Mark Kettenis]

> Date: Mon, 12 Sep 2005 16:32:20 -0400
> From: 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?

>From Richards patch I inferred that the prototype for ptrace(2)
doesn't actually match the actual system call in some cases.  That's
bad.  But I may be wrong here...

...but in that case Richard is making things hopelessly complicated by
doing using syscall() instead of ptrace().

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

Fair enough.  But this code is really getting difficult to read.  It
uses several constructs that really only made sense in the generic
code where this was copied from.

What really frustrates me is that the different Linux ports are
reinventing the wheel, all in a different way.  There are several
architectures that have the same 32x64 issues, yet there's nobody who
steps back, notices the pattern, and tries to solve the problem in a
unified way.  This makes us end up with a lot of native-dependent code
that's really hard to maintain.

Mark