From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11013 invoked by alias); 12 Sep 2006 20:28:11 -0000 Received: (qmail 11003 invoked by uid 22791); 12 Sep 2006 20:28:11 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.palmsource.com (HELO mx2.palmsource.com) (12.7.175.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Sep 2006 20:28:06 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.domain.tld (Postfix) with ESMTP id F0B3A26A16; Tue, 12 Sep 2006 13:28:04 -0700 (PDT) Received: from mx2.palmsource.com ([127.0.0.1]) by localhost (mx2.palmsource.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07395-05-5; Tue, 12 Sep 2006 13:28:01 -0700 (PDT) Received: from ussunex01.palmsource.com (unknown [192.168.101.9]) by mx2.palmsource.com (Postfix) with ESMTP id 89390269D6; Tue, 12 Sep 2006 13:28:01 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC] h8300 "info registers" fix Date: Tue, 12 Sep 2006 20:28:00 -0000 Message-ID: <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAA2@ussunex01.palmsource.com> References: From: "Michael Snyder" To: "Yoshinori Sato" , "gdb-patches" X-IsSubscribed: yes 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/msg00055.txt.bz2 > A result of ccr and exr mistakes by a "info registers" of h8300 target. > There was two faults. >=20 > - A name of E_CCR_REGNUM is not defined with h8300_register_name. > Accordingly regcache_raw_read of h8300_pseudo_regitser_read fails. > - Assume size of E_PSEUDO_CCR_REGNUM by 1 byte with h8300_register_type. > But assume 4 bytes from a remote target. > Accordingly cannot take response of remote side to be really. >=20 > I correct an issue of a thing of the patch box which I attached. > The issue was corrected, but not know you whether this is good technique. I'm sorry, but I don't think this is right.=20=20 E_CCR_REGNUM is the physical register which gdb reads from the target. This is defined to be 4 bytes, even though only 1 byte is significant. It's just easier to keep most or all of the registers to the same size within the register message packet. E_PSEUDO_CCR_REGNUM is a "pseudo-register", which gdb computes internally (rather than requesting from the target). It is defined to be 1 byte, and it is the register that gdb displays to the user. In this case, the=20 computation of the pseudo-register is simply copying the one significant byte from the physical register. The fact that E_CCR_REGNUM has no display-name is deliberate. That register is never displayed, it is only fetched from the target and used to obtain the value of E_PSEUDO_CCR_REGNUM (which is displayed). If you are working on the target side (gdb stub, simulator, or gdbserver),= =20 you only have to worry about E_CCR_REGNUM, but you need to supply it as four bytes. I forget whether the MSB or the LSB is the significant one, but you should not have too much trouble to figure it out. The other bytes can be any value - they'll be ignored. Michael