2015-01-01 09:32:14 +00:00
|
|
|
# Copyright (C) 2013-2015 Free Software Foundation, Inc.
|
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.
2013-04-22 09:20:33 +00:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
2015-07-07 15:58:19 +00:00
|
|
|
if { ![is_aarch32_target] } {
|
2013-11-11 23:58:06 +00:00
|
|
|
verbose "Skipping ${gdb_test_file_name}."
|
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.
2013-04-22 09:20:33 +00:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
standard_testfile
|
|
|
|
|
|
|
|
# We need to load the text segment in a high address. This is because
|
|
|
|
# the bug we are dealing with happened when GDB sign-extended the PC
|
|
|
|
# on ARM, causing the PC to acquire a wrong value. That's why we use
|
|
|
|
# the "-Wl,-Ttext-segment" option compile the binary.
|
|
|
|
|
|
|
|
if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} \
|
2013-04-22 09:32:21 +00:00
|
|
|
[list debug ldflags=-Wl,-Ttext-segment=0xb0000000]] } {
|
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.
2013-04-22 09:20:33 +00:00
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
if { ![runto_main] } {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
gdb_test "next" "\[0-9\]+\\s+return 0;"
|