Andrew Haley found a bug on GDB running on ARM when using

--enable-64-bit-bfd.  Basically the issue happens when dealing with "bl"
instructions: GDB does branch destination calculation and (wrongly)
sign-extends the PC.  Here is a piece of his original message explaining
the problem:

>      next_pc = arm_get_next_pc (frame, get_frame_pc (frame));
>
>      /* The Linux kernel offers some user-mode helpers in a high page.  We can
>         not read this page (as of 2.6.23), and even if we could then we couldn't
>         set breakpoints in it, and even if we could then the atomic operations
>         would fail when interrupted.  They are all called as functions and return
>         to the address in LR, so step to there instead.  */
>      if (next_pc > 0xffff0000)
>        next_pc = get_frame_register_unsigned (frame, ARM_LR_REGNUM);
>
>      arm_insert_single_step_breakpoint (gdbarch, aspace, next_pc);
>
>    Unfortunately, branch destination addresses are SIGN EXTENDED to 64
>    bits.  So,
>
>    (top-gdb) p/x next_pc
>    $14 = 0xffffffffb6df2864
>
>    Which triggers the next_pc = get_frame_register_unsigned(), and we
>    cannot step into any branches because the destination PC is wrong.

Anyway, the fix is simple and Andrew himself provided it for us.  It
took a while for me to figure out how to trigger the bug (in order to
write a testcase for it), but I finally made it.

The attached patch fixes the problem (by casting to `unsigned long'
instead of just `long'), and also includes a testcase to reproduce the
issue.

gdb/ChangeLog:

2013-04-22  Andrew Haley  <aph@redhat.com>

	* arm-tdep.c (BranchDest): Cast result as "unsigned long",
	instead of "long".

gdb/testsuite/ChangeLog:

2013-04-22  Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.arch/arm-bl-branch-dest.c: New file.
	* gdb.arch/arm-bl-branch-dest.exp: Likewise.

0 files changed, 0 insertions, 0 deletions