From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20045 invoked by alias); 15 Nov 2002 15:09:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20038 invoked from network); 15 Nov 2002 15:09:36 -0000 Received: from unknown (HELO dell.zee2.com) (212.74.13.151) by sources.redhat.com with SMTP; 15 Nov 2002 15:09:36 -0000 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id gAFF8on02795; Fri, 15 Nov 2002 10:08:51 -0500 Message-ID: <3DD50DD9.7392F27C@zee2.com> Date: Fri, 15 Nov 2002 07:09:00 -0000 From: Stuart Hughes Organization: Zee2 Ltd X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb Subject: Re: software single step References: <3DC52A84.18B7BF92@zee2.com> <20021104012251.GB7441@nevyn.them.org> <3DCFE500.8185926F@zee2.com> <20021111175057.GA5802@nevyn.them.org> <3DCFEFA0.539D1767@zee2.com> Content-Type: multipart/mixed; boundary="------------8071368EB3D6DF4738C53EA9" X-SW-Source: 2002-11/txt/msg00179.txt.bz2 This is a multi-part message in MIME format. --------------8071368EB3D6DF4738C53EA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 1515 Stuart Hughes wrote: > > Daniel Jacobowitz wrote: > > > > > > Sending packet: $m84c4,4#d0...Ack > > > Packet received: 060000ea > > > Sending packet: $M84c4,4:01009fef#15...Ack > > > Packet received: OK > > > Sending packet: $c#63...Ack > > > Packet received: T050b:e4fcffbf;0d:d4fcffbf;0f:c4840000; > > > > Same, to 0x84c4. Now this is the strange one. What happened? It > > seems to have mispredicted the next instruction when placing the > > breakpoint; the branch was presumably taken. > > > > Thanks for the pointer, I'll look into it and see if I can make any > sense of it. > Hi Daniel, Thanks for helping me track it down, I've modified the patch as you suggested and it still works on my strong-arm target. Some of the traffic for this problem went off the list, so to recap here's the reasoning for what I've done: When using gdb/gdbserver, when stepping at branches, gdb asks for a register dump by sending the 'g' remote command, gdbsever in the case of arm, sends back the first 15 registers (gdbserver/linux-arm-low.c defines num_regs to 16, and so gdbserver/linux-low.c:usr_fetch_inferior_registers actually asks for registers 0->15 via the regmap in linux-arm-low.c). If you look at gdbsever/reg-arm.c, the original regmap is only requesting register r0->pc, which doesn't include the status register. Clearly, without the status register being returned, it's not possible to correctly interpret condition codes (for branches) Thanks again for all those who helped. Regards, Stuart --------------8071368EB3D6DF4738C53EA9 Content-Type: text/plain; charset=us-ascii; name="patch-arm-gdbserver-step" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-arm-gdbserver-step" Content-length: 880 diff --exclude CVS -uNr gdb-5.2/gdb/gdbserver/linux-arm-low.c gdb-5.2.modified/gdb/gdbserver/linux-arm-low.c --- gdb-5.2/gdb/gdbserver/linux-arm-low.c Wed Feb 27 07:07:39 2002 +++ gdb-5.2.modified/gdb/gdbserver/linux-arm-low.c Fri Nov 15 10:57:28 2002 @@ -26,11 +26,13 @@ #include #endif -int num_regs = 16; +int num_regs = 26; int regmap[] = { 0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, + -1, -1, -1, -1, -1, -1, -1, -1, -1, + 64 }; int diff --exclude CVS -uNr gdb-5.2/gdb/gdbserver/linux-low.c gdb-5.2.modified/gdb/gdbserver/linux-low.c --- gdb-5.2/gdb/gdbserver/linux-low.c Thu Mar 7 20:56:18 2002 +++ gdb-5.2.modified/gdb/gdbserver/linux-low.c Fri Nov 15 13:58:39 2002 @@ -171,8 +171,6 @@ error ("Invalid register number %d.", regnum); addr = regmap[regnum]; - if (addr == -1) - addr = 0; return addr; } --------------8071368EB3D6DF4738C53EA9--