From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14813 invoked by alias); 5 Sep 2014 22:54:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14779 invoked by uid 89); 5 Sep 2014 22:54:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 05 Sep 2014 22:54:48 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s85MsgoK023236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 18:54:42 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s85MsfC7020230 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 Sep 2014 18:54:42 -0400 From: Sergio Durigan Junior To: Edjunior Barbosa Machado Cc: gdb-patches@sourceware.org, Ulrich Weigand Subject: Re: [PATCH] ppc64le/gdbserver: Fix ppc_collect/supply_ptrace_register() routines References: <1409947102-32166-1-git-send-email-emachado@linux.vnet.ibm.com> X-URL: http://www.redhat.com Date: Fri, 05 Sep 2014 22:54:00 -0000 In-Reply-To: <1409947102-32166-1-git-send-email-emachado@linux.vnet.ibm.com> (Edjunior Barbosa Machado's message of "Fri, 5 Sep 2014 16:58:22 -0300") Message-ID: <87oaut4r0u.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00162.txt.bz2 On Friday, September 05 2014, Edjunior Barbosa Machado wrote: > Hi, > > this patch fixes the routines to collect and supply ptrace registers on ppc64le > gdbserver. Originally written for big endian arch, they were causing several > issues on little endian. With this fix, the number of unexpected failures in > the testsuite dropped from 263 to 72 on ppc64le. > Tested on ppc64{,le}. Ok? Heya! Thanks for the patch. A few comments below. > gdb/gdbserver/ > 2014-09-05 Edjunior Barbosa Machado > > * linux-ppc-low.c (ppc_collect_ptrace_register): Adjust routine to take > endianness into account. > (ppc_supply_ptrace_register): Likewise. > > --- > gdb/gdbserver/linux-ppc-low.c | 37 ++++++++++++++++++++++++++++--------- > 1 file changed, 28 insertions(+), 9 deletions(-) > > diff --git a/gdb/gdbserver/linux-ppc-low.c b/gdb/gdbserver/linux-ppc-low.c > index d743311..1898741 100644 > --- a/gdb/gdbserver/linux-ppc-low.c > +++ b/gdb/gdbserver/linux-ppc-low.c > @@ -202,25 +202,44 @@ ppc_cannot_fetch_register (int regno) > static void > ppc_collect_ptrace_register (struct regcache *regcache, int regno, char *buf) > { > - int size = register_size (regcache->tdesc, regno); > - > memset (buf, 0, sizeof (long)); > > - if (size < sizeof (long)) > - collect_register (regcache, regno, buf + sizeof (long) - size); > + if (__BYTE_ORDER == __LITTLE_ENDIAN) Why not use gdbarch_byte_order here? We don't use __BYTE_ORDER anywhere in the code. > + { > + /* Little-endian values always sit at the left end of the buffer. */ > + collect_register (regcache, regno, buf); > + } > + else if (__BYTE_ORDER == __BIG_ENDIAN) > + { > + /* Big-endian values sit at the right end of the buffer. In case of "... of the buffer. In case..." Two spaces after period :-). > + registers whose size is smaller than sizeof (long), we must use a I'd prefer: s/size is/sizes are/ > + padding to access it correctly. */ s/it/them/ > + int padding = (sizeof (long) - register_size (regcache->tdesc, regno)); > + collect_register (regcache, regno, buf + padding); Please leave an empty newline between the declaration of the variable and the rest of the code. > + } > else > - collect_register (regcache, regno, buf); > + perror_with_name ("Unexpected byte order"); > } > > static void > ppc_supply_ptrace_register (struct regcache *regcache, > int regno, const char *buf) > { > - int size = register_size (regcache->tdesc, regno); > - if (size < sizeof (long)) > - supply_register (regcache, regno, buf + sizeof (long) - size); > + if (__BYTE_ORDER == __LITTLE_ENDIAN) > + { > + /* Little-endian values always sit at the left end of the buffer. */ > + supply_register (regcache, regno, buf); > + } > + else if (__BYTE_ORDER == __BIG_ENDIAN) > + { > + /* Big-endian values sit at the right end of the buffer. In case of > + registers whose size is smaller than sizeof (long), we must use a > + padding to access it correctly. */ > + int padding = (sizeof (long) - register_size (regcache->tdesc, regno)); > + supply_register (regcache, regno, buf + padding); > + } > else > - supply_register (regcache, regno, buf); > + perror_with_name ("Unexpected byte order"); > } Same applies for this chunk. Otherwise, looks good (it's not an approval). Cheers, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/