old-cross-binutils/gdb/testsuite/gdb.arch/arm-bl-branch-dest.exp

38 lines
1.3 KiB
Text
Raw Normal View History

# 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/>.
if { ![is_aarch32_target] } {
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} \
[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;"