Re: [RFA] gdbserver fetch/store registers problem on s390x

[Daniel Jacobowitz <drow@false.org>]

Hi Ulrich,

On Tue, May 10, 2005 at 06:54:28PM +0200, Ulrich Weigand wrote:
> Hello,
> 
> this patch fixes another problem with gdbserver on s390x occurring
> on recent kernels.  The problem is that some registers accessed by
> ptrace (notably the access registers and the floating-point status
> register) are still 32 bits wide, even though the PTRACE_PEEKUSER
> and PTRACE_POKEUSER commands always transfer 64 bits.
> 
> This is a problem for two reasons: when fetching those registers,
> a 4-byte buffer is allocated via alloca, but then 8 bytes are 
> written to that buffer (which just happens to work because alloca
> rounds the size up to the next multiple of 8 anyway).  The same
> holds for storing the register; but in this case the second 4 bytes
> have just random contents, and recent kernels won't allow the POKEUSER
> command to succeed unless those extra bytes are zero.

While this patch was fine, it did make me take a closer look at what's
going on.  I've got a couple questions :-)  The kernel sources weren't
too enlightening, except that whoever maintains ptrace for s390 really
doesn't like GDB.

When you access the acrs, it looks like we are actually peeking/poking
two of them at once.  I didn't see any sign of the "rest must be
zeroed" you mentioned.  Is this in code not currently contributed to
kernel.org?

In the current code the ACR we want to be poking at is the
low-memory-address end of the buffer, i.e. leftmost in a big endian
system (which all supported s390 appears to be).  Is that right?

This is unfortunate... it means I need another target knob, since the
PPC64 FPSCR is definitively in the rightmost 32 bits of the ptrace
xfer.


-- 
Daniel Jacobowitz
CodeSourcery, LLC