From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30701 invoked by alias); 13 Jul 2005 01:35:53 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30691 invoked by uid 22791); 13 Jul 2005 01:35:49 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 13 Jul 2005 01:35:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DsWA8-0004jI-CN; Tue, 12 Jul 2005 21:35:48 -0400 Date: Wed, 13 Jul 2005 01:35:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] gdbserver fetch/store registers problem on s390x Message-ID: <20050713013548.GA17999@nevyn.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sources.redhat.com References: <200505101654.j4AGsTCj028703@53v30g15.boeblingen.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505101654.j4AGsTCj028703@53v30g15.boeblingen.de.ibm.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00109.txt.bz2 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