This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa/arm] Handle bx and blx
On Mon, Mar 08, 2004 at 02:19:29PM +0000, Richard Earnshaw wrote:
> > On Mon, Mar 08, 2004 at 10:17:53AM +0000, Richard Earnshaw wrote:
> > > > On Wed, Mar 03, 2004 at 04:01:55PM +0000, Richard Earnshaw wrote:
> > > > > > The software single-step implementation in GDB doesn't know either BX or
> > > > > > BLX. This results in losing control of the inferior when we single-step
> > > > > > over them. I based this on the ARM ARM, so I'm pretty sure I've got the
> > > > > > numbers correct.
> > > > > >
> > > > > > OK to check in?
> > > > > >
> > > > > > --
> > > > > > Daniel Jacobowitz
> > > > > > MontaVista Software Debian GNU/Linux Developer
> > > > > >
> > > > > > 2004-02-28 Daniel Jacobowitz <drow@mvista.com>
> > > > > >
> > > > > > * arm-tdep.c (thumb_get_next_pc): Handle BX.
> > > > > > (arm_get_next_pc): Handle BX and BLX.
> > > > >
> > > > > Yikes! Yes, this is OK. However, Thumb has BLX (2 variants) as well.
> > > >
> > > > Right you are. I've checked in the above; if I'm reading
> > > > thumb_get_next_pc and the ARM correctly, then the below is all I need
> > > > for BLX. The first form is already handled since we don't check H.
> > > > The second form can be handled identically to BX by relaxing a test.
> > > >
> > > > OK?
> > > >
> > > > --
> > > > Daniel Jacobowitz
> > > > MontaVista Software Debian GNU/Linux Developer
> > > >
> > > > 2004-03-07 Daniel Jacobowitz <drow@mvista.com>
> > > >
> > > > * arm-tdep.c (thumb_get_next_pc): Handle Thumb BLX.
> > >
> > > Very close, and possibly good enough for most purposes. But the ARM ARM
> > > says that in the blx(1) case, the resulting address should be masked with
> > > 0xfffffffc. That means that there are two theoretical encodings for each
> > > target ARM-state instruction. I think you need to add a test for H=01 and
> > > if so, to apply the mask to nextpc.
> >
> > Except it also says:
> > Bit[0] for BLX If H == 01, then bit[0] of the instruction must
> > be zero, or the instruction is UNDEFINED.
> > The offset calculation method described
> > in Usage above ensures that the offset
> > calculated for a BLX instruction is a
> > multiple of four, and that this
> > restriction is obeyed.
> >
> > So I think the mask really isn't needed, or am I reading that wrong?
>
> Ah, missed that bit. However, we could be starting with a pc value where
> pc[1] != 0, so we still need the mask.
Ahh, that's right. The offset will be a multiple of four but the
PC+offset may not be. This OK then?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2004-03-08 Daniel Jacobowitz <drow@mvista.com>
* arm-tdep.c (thumb_get_next_pc): Handle Thumb BLX.
Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.165
diff -u -p -r1.165 arm-tdep.c
--- arm-tdep.c 7 Mar 2004 20:03:12 -0000 1.165
+++ arm-tdep.c 8 Mar 2004 14:24:49 -0000
@@ -1651,13 +1651,16 @@ thumb_get_next_pc (CORE_ADDR pc)
{
nextpc = pc_val + (sbits (inst1, 0, 10) << 1);
}
- else if ((inst1 & 0xf800) == 0xf000) /* long branch with link */
+ else if ((inst1 & 0xf800) == 0xf000) /* long branch with link, and blx */
{
unsigned short inst2 = read_memory_integer (pc + 2, 2);
offset = (sbits (inst1, 0, 10) << 12) + (bits (inst2, 0, 10) << 1);
nextpc = pc_val + offset;
+ /* For BLX make sure to clear the low bits. */
+ if (bits (inst2, 11, 12) == 1)
+ nextpc = nextpc & 0xfffffffc;
}
- else if ((inst1 & 0xff80) == 0x4700) /* branch and exchange (bx) */
+ else if ((inst1 & 0xff00) == 0x4700) /* bx REG, blx REG */
{
if (bits (inst1, 3, 6) == 0x0f)
nextpc = pc_val;