GDB tests running on arm target should be also run on aarch32
(32-bit mode on aarch64). There should be no difference. It is not
precise to check target triplet to decide which tests should be run,
because if I compiler all the test binary in 32-bit (arm program),
but target triplet is still aarch64, so that these arm specific tests
are skipped.
This patch is to add a new proc is_aarch32_target which return true
if target triplet is arm or the test binary is compiled for arm.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (is_aarch32_target): New proc.
* gdb.arch/arm-bl-branch-dest.exp: Check is_aarch32_target
instead of "istarget "arm*-*-*"".
* gdb.arch/arm-disp-step.exp: Likewise.
* gdb.arch/thumb-bx-pc.exp: Likewise.
* gdb.arch/thumb-prologue.exp: Likewise.
* gdb.arch/thumb-singlestep.exp: Likewise.
* gdb.base/disp-step-syscall.exp: Likewise.
* gdb.base/float.exp: Likewise.
--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.
