From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-67968-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 23399 invoked by alias); 23 Oct 2009 16:07:18 -0000
Received: (qmail 23389 invoked by uid 22791); 23 Oct 2009 16:07:17 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Oct 2009 16:07:11 +0000
Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) 	by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 6F53C33051; 	Fri, 23 Oct 2009 09:07:10 -0700 (PDT)
Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) 	by mailhost4.vmware.com (Postfix) with ESMTP id 63D87C9C50; 	Fri, 23 Oct 2009 09:07:10 -0700 (PDT)
Message-ID: <4AE1D314.4030601@vmware.com>
Date: Fri, 23 Oct 2009 16:07:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: Pierre Muller <muller@ics.u-strasbg.fr>
CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: New ARI regression Fri Oct 23 01:57:01 UTC 2009
References: <20091023015701.GA26378@sourceware.org> <006301ca53be$eedd1b80$cc975280$@u-strasbg.fr>
In-Reply-To: <006301ca53be$eedd1b80$cc975280$@u-strasbg.fr>
Content-Type: multipart/mixed;  boundary="------------080209000709040805000406"
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-10/txt/msg00591.txt.bz2

This is a multi-part message in MIME format.
--------------080209000709040805000406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-length: 383

Pierre Muller wrote:
> Is there a valid reason to use LITTLE_ENDIAN rather than
> BFD_LITTLE_ENDIAN as required by the ARI rule:
> 
> LITTLE ENDIAN	3	Do not use LITTLE_ENDIAN, instead use
> BFD_ENDIAN_LITTLE
> See:
> http://sourceware.org/gdb/current/ari/
> 
> Pierre Muller
> as ARI "maintainer"


Thanks Pierre.  Checked in as obvious.

So let it be written -- so let it be done.


--------------080209000709040805000406
Content-Type: text/plain;
 name="little.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="little.txt"
Content-length: 1169

2009-10-23  Michael Snyder  <msnyder@vmware.com>

	* record.c (netorder64): Use BFD_ENDIAN_LITTLE not LITTLE_ENDIAN.
	(netorder32): Ditto.
	(netorder16): Ditto.

Index: record.c
===================================================================
RCS file: /cvs/src/src/gdb/record.c,v
retrieving revision 1.30
diff -u -p -r1.30 record.c
--- record.c	22 Oct 2009 19:36:06 -0000	1.30
+++ record.c	23 Oct 2009 16:05:47 -0000
@@ -1955,7 +1955,7 @@ bfdcore_read (bfd *obfd, asection *osec,
 static inline uint64_t
 netorder64 (uint64_t fromfile)
 {
-  return (BYTE_ORDER == LITTLE_ENDIAN) 
+  return (BYTE_ORDER == BFD_ENDIAN_LITTLE) 
     ? bswap_64 (fromfile) 
     : fromfile;
 }
@@ -1963,7 +1963,7 @@ netorder64 (uint64_t fromfile)
 static inline uint32_t
 netorder32 (uint32_t fromfile)
 {
-  return (BYTE_ORDER == LITTLE_ENDIAN) 
+  return (BYTE_ORDER == BFD_ENDIAN_LITTLE) 
     ? bswap_32 (fromfile) 
     : fromfile;
 }
@@ -1971,7 +1971,7 @@ netorder32 (uint32_t fromfile)
 static inline uint16_t
 netorder16 (uint16_t fromfile)
 {
-  return (BYTE_ORDER == LITTLE_ENDIAN) 
+  return (BYTE_ORDER == BFD_ENDIAN_LITTLE) 
     ? bswap_16 (fromfile) 
     : fromfile;
 }

--------------080209000709040805000406--