ppc32 debugging ppc64, 2011 revisit

ppc32 debugging ppc64, 2011 revisit

[Stan Shebs]

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?

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

3. Does anybody have an up-to-date Linux running on PPC64 hw that I 
could use?  There seem to be fewer compile farms around than formerly, 
and the in-house machine is very old and may not survive a kernel 
update, so we don't want to mess with it too much right now.

Stan
stan@codesourcery.com

Re: ppc32 debugging ppc64, 2011 revisit

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> But in the usual way, when preparing for submission, I discover that
Stan> rth had posted similar code to solve the same problem - back in 2005!
Stan> It's at http://www.cygwin.com/ml/gdb-patches/2005-09/msg00082.html ,
Stan> and there's even a bit of discussion thread; but it seems nothing was
Stan> ever committed.

Stan> 1. Does anybody remember a fatal flaw, or was the patch simply
Stan> forgotten about?

I asked rth, but I think the question just re-traumatized him.
He said maybe he just gave up trying to get it in.

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

I don't know enough to comment.

Stan> 3. Does anybody have an up-to-date Linux running on PPC64 hw that I
Stan> could use?  There seem to be fewer compile farms around than formerly,
Stan> and the in-house machine is very old and may not survive a kernel
Stan> update, so we don't want to mess with it too much right now.

The GCC Compile Farm has some.  You can easily get an account:

    http://gcc.gnu.org/wiki/CompileFarm

Search that page for "powerpc"; I ssh'd in to gcc38 without trouble:

tromey@ps3gccfarm:~$ uname -a
Linux ps3gccfarm 2.6.32-3-powerpc64 #1 SMP Thu Feb 25 08:18:03 UTC 2010 ppc64 GNU/Linux


I don't know how up-to-date this is but the compile farm maintainers are
reasonably responsive.

Tom

Re: ppc32 debugging ppc64, 2011 revisit

[Mark Kettenis]

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

Re: ppc32 debugging ppc64, 2011 revisit

[Stan Shebs]

On 7/23/11 2:38 PM, Mark Kettenis wrote:
>> Date: Mon, 18 Jul 2011 18:19:14 -0700
>> From: Stan Shebs<stanshebs@earthlink.net>
>> 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.

The cloning is a bit messy, because there are a couple additional call 
layers with heuristics for /proc reading and so forth, while the ifdef 
version adds about 10 lines total.  In any case, I'll just post the 
patch and then count the number of fingers being poked down throats. :-)

Stan
stan@codesourcery.com