From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16928 invoked by alias); 3 Feb 2003 20:30:55 -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 16921 invoked from network); 3 Feb 2003 20:30:55 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 3 Feb 2003 20:30:55 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h13KUtf12130 for ; Mon, 3 Feb 2003 15:30:55 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h13KUsn31671; Mon, 3 Feb 2003 15:30:54 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h13KUrQ13794; Mon, 3 Feb 2003 12:30:53 -0800 Message-ID: <3E3ED17D.3BA10C33@redhat.com> Date: Mon, 03 Feb 2003 20:30:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Kazu Hirata CC: gdb-patches@sources.redhat.com Subject: Re: Unreviewed patches References: <3E39E145.A5B01D17@redhat.com> <20030130.234517.112286807.kazu@cs.umass.edu> <3E3B229D.67F2E805@redhat.com> <20030131.222329.93642824.kazu@cs.umass.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00086.txt.bz2 Kazu Hirata wrote: > > Hi Michael, > > > Yes, thanks. My problem is this: your patch uses a host-order > > sign-extend to simulate a target-order sign-extend. If the host > > and target have different byte orders, you lose. That's probably > > why the simulator uses breg[] to fetch bytes, instead of using > > wreg and masking. > > > > I suggest that it would be comparatively easy to extend the > > breg[] array so that it would cover at least the first three > > bytes in the register (and possibly all four, just because > > it's no extra effort). Something like the attached. > > > > Then the code that references breg[] does not need to change. > > I understand your concern. But then if GET_W_REG may give a > byte-swapped value, would the following be endian unsafe? > > case O (O_ADD, SW): > rd = GET_W_REG (code->dst.reg); > ea = fetch (&code->src); > res = rd + ea; > goto alu16; > > The addition is done in host-order. I don't know, other than to say that it evidently works. However in this case we are fetching a half-word as a half-word. In the other case, we are fetching a byte as a half-word, and assuming (incorrectly, I think) that the byte we actually want will be in the lower half of the half-word. If you look at the existing code for initializing breg, it obviously goes to some effort to avoid making that assumption.