Re: ppc32 debugging ppc64, 2011 revisit

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

> Date: Mon, 18 Jul 2011 18:19:14 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> So Mentor Embedded Linux has a need for a run-anywhere native GDB for 
> PowerPC, meaning in practice that we want a 32-bit GDB that can debug 
> both 32- and 64-bit programs.  So I imagine I'm clever, and steal some 
> bits from spu-linux-nat.c that use the *_3264 ptrace() commands that are 
> the defined way to get at a 64-bit program from 32-bit land, and it 
> works reasonably well, modulo various system hangs and crashes due to 
> 32-x-64 lameness in the oldish version of PPC Linux we have in-house.
> 
> But in the usual way, when preparing for submission, I discover that rth 
> had posted similar code to solve the same problem - back in 2005! It's 
> at http://www.cygwin.com/ml/gdb-patches/2005-09/msg00082.html , and 
> there's even a bit of discussion thread; but it seems nothing was ever 
> committed.
> 
> So I have a couple questions:
> 
> 1. Does anybody remember a fatal flaw, or was the patch simply forgotten 
> about?

Reading through the discussion again, I think the problems with the
ptrace(2) prototype provided by glibc is what made rth give up on this.

> 2. The old patch works by making a clone of the generic xfer_partial, to 
> accommodate the randomly-different API of the 32-x-64 ptrace commands, 
> but I added #ifdef cases to inf-ptrace.c, which actually seemed cleaner, 
> and avoided duplicating the semi-complicated algorithm.  (Yes yes, 
> ifdefs are evil, but keep in mind that inf-ptrace.c is inherently 
> native-only.)

Indeed, ifdefs are generally ok in native-only code, but we should
avoid things turning into an ifdef maze.  I don't know hiw invaisive
your changes are, but I think you should consider cloning the bits of
inf_ptrace_xfer_partial() that are relevant into ppc-linux-nat.c and
make your changes there.  If you substitute the appropriate types for
PTRACE_RET_TYPE and PTRACE_TYPE_ARG3, the code will be more readable.
Also, you probably don't need to worry about PT_WRITE_D
vs. PT_WRITE_I.