From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1519 invoked by alias); 13 Sep 2006 02:28:10 -0000 Received: (qmail 1510 invoked by uid 22791); 13 Sep 2006 02:28:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail1.asahi-net.or.jp (HELO mail.asahi-net.or.jp) (202.224.39.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Sep 2006 02:28:07 +0000 Received: from mitou.ysato.dip.jp (l247150.ppp.asahi-net.or.jp [218.219.247.150]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 53F2A13EF9; Wed, 13 Sep 2006 11:28:05 +0900 (JST) Received: from ysato.dip.jp (mitou [127.0.0.1]) by mitou.ysato.dip.jp (Postfix) with ESMTP id 45C001C18A; Wed, 13 Sep 2006 11:28:05 +0900 (JST) Received: from 222.228.157.137 (proxying for unknown) (SquirrelMail authenticated user ysato) by ysato.dip.jp with HTTP; Wed, 13 Sep 2006 11:28:05 +0900 (JST) Message-ID: <62106.222.228.157.137.1158114485.squirrel@ysato.dip.jp> In-Reply-To: <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAA2@ussunex01.palmsource.com> References: <0F4DF2E21F33DD46BE7B8CDEEB0E16D307EAA2@ussunex01.palmsource.com> Date: Wed, 13 Sep 2006 02:28:00 -0000 Subject: RE: [RFC] h8300 "info registers" fix From: "Yoshinori Sato" To: "Michael Snyder" Cc: "gdb-patches" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit 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/msg00057.txt.bz2 > >> A result of ccr and exr mistakes by a "info registers" of h8300 target. >> There was two faults. >> >> - 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. >> >> 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. > > 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 > computation of the pseudo-register is simply copying the one significant > byte from the physical register. The size is converted by the access of a pseudo 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). Because legacy_register_sim_regno was not able to judge the register number correctly, it corrected it. However, it is necessary to evade this problem with register_sim_regno. It corrects it like that. > If you are working on the target side (gdb stub, simulator, or gdbserver), > 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 > Thank you for the advice that becomes reference very much. -- Yoshinori Sato