From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19504 invoked by alias); 23 Sep 2006 01:08:56 -0000 Received: (qmail 19496 invoked by uid 22791); 23 Sep 2006 01:08:56 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 23 Sep 2006 01:08:54 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k8N18H7N015477; Sat, 23 Sep 2006 03:08:17 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.8/8.13.6) with ESMTP id k8N18Hkh011371; Sat, 23 Sep 2006 03:08:17 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k8N18HNY019655; Sat, 23 Sep 2006 03:08:17 +0200 (CEST) Date: Sat, 23 Sep 2006 01:08:00 -0000 Message-Id: <200609230108.k8N18HNY019655@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: Michael.Snyder@palmsource.com CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAB4@ussunex01.palmsource.com> (Michael.Snyder@palmsource.com) Subject: Re: [RFC] h8300 "info registers" fix References: <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAB2@ussunex01.palmsource.com> <20060913200917.GA20574@nevyn.them.org> <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAB3@ussunex01.palmsource.com> <20060913203043.GB21009@nevyn.them.org> <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAB4@ussunex01.palmsource.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00156.txt.bz2 > Date: Wed, 13 Sep 2006 13:49:26 -0700 > From: "Michael Snyder" > > Daniel: > >On Wed, Sep 13, 2006 at 01:20:09PM -0700, Michael Snyder wrote: > >> Grumble -- is the regcache kept in host order, or target order? > > > >Target order. > > > >[Which is apparently a bit weird; most debug interfaces I've seen > >lately use host order.] > > That's right -- it's a relic of the fact that the original > "register cache" was the register packet itself, which is > generated on the target side. The target doesn't know anything > about the host, so there's no way that can be in host order. > > Anyway, in that case, the gdb_byte[4] approach is more likely > to be correct, eh? Yes, gdb_byte is the type we use for target byte buffers. > I think I understand the problem now -- the pseudo-register is > only one byte, so it's "natural" to call pseudo_register_read > with a one byte buffer. But the physical register is four bytes, > so you have to have a four byte buffer to read it. > > Wonder why it ever worked? ;-/ The fact that almost all variables on a 32-bit machines are word-aligned? Mark