From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31079 invoked by alias); 15 Aug 2013 04:34:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31061 invoked by uid 89); 15 Aug 2013 04:34:36 -0000 X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 15 Aug 2013 04:34:35 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7F4YYCv031834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Aug 2013 00:34:34 -0400 Received: from localhost.localdomain (ovpn-113-55.phx2.redhat.com [10.3.113.55]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7F4YY4E023539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Aug 2013 00:34:34 -0400 Date: Thu, 15 Aug 2013 04:34:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [RFC] rl78-tdep.c: Make PC a pseudo-register Message-ID: <20130814213433.2422be23@redhat.com> In-Reply-To: <20130814140446.GC11128@adacore.com> References: <20130808205554.070f72ce@redhat.com> <20130814140446.GC11128@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00394.txt.bz2 Hi Joel, On Wed, 14 Aug 2013 07:04:46 -0700 Joel Brobecker wrote: > I am not an expert by any means, but I thought that this type > of situation is usually handled the way you just did with this > patch. For instance, 32bit mode with 64bit registers... Thanks for looking it over. I'll probably end up committing it after formatting issues that you noticed. > > @@ -94,7 +94,7 @@ enum > > RL78_PSW_REGNUM, /* 8 bits */ > > RL78_ES_REGNUM, /* 8 bits */ > > RL78_CS_REGNUM, /* 8 bits */ > > - RL78_PC_REGNUM, /* 20 bits; we'll use 32 bits for it. */ > > + RL78_RAW_PC_REGNUM, /* 20 bits; we'll use 32 bits for it. */ > > > > /* Fixed address SFRs (some of those above are SFRs too.) */ > > RL78_SPL_REGNUM, /* 8 bits; lower half of SP */ > > @@ -105,7 +105,8 @@ enum > > RL78_NUM_REGS, > > > > /* Pseudo registers. */ > > - RL78_SP_REGNUM = RL78_NUM_REGS, > > + RL78_PC_REGNUM = RL78_NUM_REGS, > > + RL78_SP_REGNUM, > > Out of curiosity, why not include RL78_SP_REGNUM in RL78_NUM_REGS? Before, RL78_SP_REGNUM was the first pseudo-register. Now, RL78_PC_REGNUM will be the first pseudo-register and SP will be the second. I did it this way to preserve the register order in "info registers". There is less user visible change this way. > > if ((regnum < RL78_NUM_REGS > > && regnum != RL78_SPL_REGNUM > > - && regnum != RL78_SPH_REGNUM) > > - || regnum == RL78_SP_REGNUM) > > + && regnum != RL78_SPH_REGNUM > > + && regnum != RL78_RAW_PC_REGNUM) > > + || regnum == RL78_SP_REGNUM > > + || regnum == RL78_PC_REGNUM) > > FYI, there is an inconsistent use of tabs vs spaces that made the review > of this change a little harder... I'll adjust this before committing. > > + else if (reg == RL78_PC_REGNUM) > > + { > > + gdb_byte rawbuf[4]; > > + memcpy (rawbuf, buffer, 3); > > + rawbuf[3] = 0; > > + regcache_raw_write (regcache, RL78_RAW_PC_REGNUM, rawbuf); > > + } > > In both hunks, you're missing an empty line after the rawbuf > variable declaration (one of the many coding rules of the GDB > project). I'll fix that too. > Other than that, I didn't see anything obviously wrong with the patch. Thanks again for looking it over. Much appreciated. Kevin