From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21011 invoked by alias); 1 Dec 2004 23:32:24 -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 20968 invoked from network); 1 Dec 2004 23:32:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 1 Dec 2004 23:32:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB1NWATq029703 for ; Wed, 1 Dec 2004 18:32:11 -0500 Received: from localhost.redhat.com (vpn50-50.rdu.redhat.com [172.16.50.50]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB1NWAr16070; Wed, 1 Dec 2004 18:32:10 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2F227129D8C; Wed, 1 Dec 2004 18:31:02 -0500 (EST) Message-ID: <41AE5434.9050901@gnu.org> Date: Wed, 01 Dec 2004 23:32:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/RFA] multiarch INSTRUCTION_NULLIFIED References: <20041128184141.GG6359@tausq.org> <41AA2D08.3030304@gnu.org> <20041129033013.GJ6359@tausq.org> <41AB3C1D.80509@gnu.org> <20041130065620.GT6359@tausq.org> <41AC88B2.5070501@gnu.org> <20041130164401.GV6359@tausq.org> <41ACA6BE.5080603@gnu.org> <20041130173841.GW6359@tausq.org> <41AE3759.3030503@gnu.org> <20041201223243.GK6359@tausq.org> In-Reply-To: <20041201223243.GK6359@tausq.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00035.txt.bz2 Randolph Chung wrote: >>Anyway, trying modifying gdbarch_read_pc and unwind_pc (I suspect you >>need to modify both - which is a bug) to read something like: >> >> if (instruction nullified) >> return next-pc >> else >> return this-pc > > > i did s/next-pc/prev-pc/ instead... still seems a bit hacky to me, but > it does seem to work. > @@ -1049,7 +1089,17 @@ hppa_target_read_pc (ptid_t ptid) > if (flags & 2) > return read_register_pid (31, ptid) & ~0x3; > > - return read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3; > + pc = read_register_pid (HPPA_PCOQ_HEAD_REGNUM, ptid) & ~0x3; > + > + /* If the current instruction is nullified, then we are effectively > + still executing the previous instruction. Pretend we are still > + there. This is needed when single stepping; if the nullified instruction > + is on a different line, we don't want gdb to think we've stepped onto > + that line. */ > + if (ipsw & 0x00200000) > + pc -= 4; > + > + return pc; > } On the SPARC architecture you can do things like: branch foo branch bar which leads to more warped combinations such as (assuming I've got my diagram right): f+0: branch x+c f+4: branch x+8 x+0: branch e+4 x+4: branch e+0 x+8: branch x+0 x+c: branch,annulled x+4 and I'm fairly sure that results in: f+0 f+4 [x+c] f+4 x+c [x+8] x+c --- [x+4] --- x+4 [x+8] <-------- {npc+4} x+4 x+8 [e+0] x+8 e+0 [x+0] e+0 x+0 .... and hence the ``---'' anulled instruction at x+8 has a prev-pc of x+c (pc+4) and not x+4 (pc-4). This is why I was thinking that next-pc is better (but the above could be wrong - my sparc is very very rusty :-(). Either way, yes ok (and thanks!) Andrew PS: No it's not a hack, XXX_pc projects the hardware onto an idealized machine, there are always perverse edge cases. PPS: A gdb.arch/ addition to tickle the basic edge case would be a helpful way of capturing this knowledge.