binutils-gdb/gdb/testsuite/gdb.base/break-include.exp

35 lines
1.2 KiB
Plaintext
Raw Normal View History

wrong line number in breakpoint location Consider the following situation, where we have one file containing... $ cat -n body.inc 1 i = i + 1; ... we include that file from some code, like so: $ cat -n cat -n small.c [...] 17 int 18 next (int i) 19 { 20 #include "body.inc" 21 return i; 22 } When trying to insert a breakpoint on line 18, for instance: (gdb) b small.c:18 Breakpoint 1 at 0x40049f: file body.inc, line 18. ^^ || Here, the issue is that GDB reports the breakpoint to be in file body.inc, which is true, but with the line number that corresponding to the user-requested location, which is not correct. Although the simple reproducer may look slightly artificial, the above is simply one way to reproduce the same issue observed when trying to insert a breakpoint on a function provided in a .h files and then subsequently inlined in a C file. What happens is the following: 1. We resolve the small.c:18 linespec into a symtab_and_line which has "small.c" and 18 as the symtab and line number. 2. Next, we call skip_prologue_sal, which calculates the PC past the prologue, and updates the symtab_and_line: PC, but also symtab (now body.inc) and the new line (now 1). 3. However, right after that, we do: /* Make sure the line matches the request, not what was found. */ intermediate_results.sals[i].line = val.line; We should either restore both symtab and line, or leave the actual line to match the actual symtab. This patch chose the latter. This introduces a few changes in a few tests, which required some updates, but looking at those change, I believe them to be expected. gdb/ChangeLog: * linespec.c (create_sals_line_offset): Remove code that preserved the symtab_and_line's line number. gdb/testsuite/ChangeLog: * gdb.base/break-include.c, gdb.base/break-include.inc, gdb.base/break-include.exp: New files. * gdb.base/ending-run.exp: Minor adaptations due to the breakpoint's line number now being the actual line number where the breakpoint was inserted. * gdb.mi/mi-break.exp: Likewise. * gdb.mi/mi-reverse.exp: Likewise. * gdb.mi/mi-simplerun.exp: Ditto. Tested on x86_64-linux.
2018-01-22 05:14:50 +01:00
# This testcase is part of GDB, the GNU debugger.
# Copyright 2016-2018 Free Software Foundation, Inc.
# 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/>.
standard_testfile
if { [prepare_for_testing ${testfile}.exp $testfile] } {
return -1
}
set bp_line [gdb_get_line_number "break here" ${testfile}.c]
set bp_line_actual [gdb_get_line_number "ANCHOR" ${testfile}.inc]
gdb_test "break $testfile.c:$bp_line" \
".*Breakpoint.*$testfile.inc, line $bp_line_actual\\."
# Might as well verify that breaking on function "next" gives
# the same result...
gdb_test "break next" \
".*Breakpoint.*$testfile.inc, line $bp_line_actual\\."