AltiVec register ptrace support

[Kevin Buettner]

On Dec 7,  2:57pm, Kumar Gala wrote:

> I have two different patches to the ptrace mechanism to add support
> for AltiVec registers.
>
> linux-2.4.8-altivec-ptrace.patch:  Adds support similar to existing
> mechanisms to get/set registers via PEEK/POKE calls extending the FPU
> model.
>
> linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
> that match sparc/x86 PTRACE_{GET,SET}*REGS.  These dump the full register
> state in a single call.
>
> Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
> for 2.4.x.  RedHat is trying to push out some GDB changes for AltiVec that
> require closure on this matter.

I would like to better understand your reasons for preferring
PTRACE_{GET,SET}*REGS.  Is it just because that's what x86 does
or do you think that this mechanism improves GDB's performance?

My personal opinion is that GETREGS/SETREGS does not greatly enhance
performance.  Try running strace on gdb debugging itself on x86 and on
PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
PTRACE_????  calls on x86.  (The ????  is printed because strace
doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
tried it just a moment ago using gdb to debug itself and running to a
breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
PEEKUSR/POKUSR calls on PPC.  Now, I admit that my testing wasn't very
exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
higher, I think you'd find that calls to PEEKTEXT (for prologue
analysis) would dominate.  I.e, the majority of the ptrace() traffic
is due to reading memory, not reading registers.

Furthermore, I think that introducing GETREGS/SETREGS will make
ppc-linux-nat.c (in the GDB sources) more complicated.  We'll need
compile time tests to check for the presence of GETREGS/SETREGS and
use these mechanisms if they exist.  If they don't, this code will
have to fall back to using the old PEEKUSR/POKEUSR mechanism.  Also,
it may be necessary to have runtime tests which attempt to use
GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR.  In order to
see just how messy it can get, take a look at i386-linux-nat.c.

For the reasons stated above, I prefer your PEEKUSR/POKEUSR patch.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/