From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-36679-listarch-gdb-patches=sources.redhat.com@sources.redhat.com>
Received: (qmail 21674 invoked by alias); 4 Nov 2004 00:21:43 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 21650 invoked from network); 4 Nov 2004 00:21:42 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 4 Nov 2004 00:21:42 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA40Lfw9025720
	for <gdb-patches@sources.redhat.com>; Wed, 3 Nov 2004 19:21:41 -0500
Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA40Lar24074;
	Wed, 3 Nov 2004 19:21:36 -0500
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP id A7BFC129D8C;
	Wed,  3 Nov 2004 19:21:28 -0500 (EST)
Message-ID: <41897607.1000202@gnu.org>
Date: Thu, 04 Nov 2004 00:21:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20041020)
MIME-Version: 1.0
To: Kei Sakamoto <sakamoto.kei@renesas.com>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFA/m32r] Fix breakpoint bug
References: <01b101c4ac37$3adbf950$5169910a@E5A02646> <20041025153816.GA28488@nevyn.them.org> <002001c4bb1f$20031630$5169910a@E5A02646>
In-Reply-To: <002001c4bb1f$20031630$5169910a@E5A02646>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-11/txt/msg00053.txt.bz2

Kei Sakamoto wrote:
 >Daniel wrote:
>>I'm curious about the little endian case:
>>
>>+  else /* little-endian */
>>+    {
>>+      if ((addr & 3) == 0)
>>+ {
>>+   buf[0] = contents_cache[0];
>>+   buf[1] = contents_cache[1] & 0x7f;
>>+   buf[2] = bp_entry[1];
>>+   buf[3] = bp_entry[0];
>>  }
>>
>>Shouldn't the breakpoint be placed at buf[0] here rather than buf[2]?
> 
> 
> For most of architectures - yes, it shold be at buf[0]. But the little endian
> mode of M32R is a kind of unique.
> 
> In other architectures, two 16-bit instructions, A and B, are placed as
> the following:
> 
> Big endian:
> A0 A1 B0 B1
> 
> Little endian:
> A1 A0  B1 B0
> 
> In M32R, they are placed like this:
> 
> Big endian:
> A0 A1 B0 B1
> 
> Little endian:
> B1 B0 A1 A0
> 
> This is because M32R always fetches instructions in 32-bit.
> So the breakpoint should be placed at buf[2].

Then this is ok (mainline and 6.3).  I'd add a comment explaining the 
above before committing though.

sorry for the delay,
Andrew