2020-01-01 14:20:01 +08:00
|
|
|
# Copyright 2015-2020 Free Software Foundation, Inc.
|
2015-10-16 16:08:19 +08: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/>.
|
|
|
|
load_lib dwarf.exp
|
|
|
|
|
|
|
|
# Test DW_TAG_compile_unit with no children and with neither DW_AT_low_pc nor
|
|
|
|
# DW_AT_high_pc but with DW_AT_ranges instead.
|
|
|
|
|
|
|
|
# This test can only be run on targets which support DWARF-2 and use gas.
|
|
|
|
if {![dwarf2_support]} {
|
|
|
|
verbose "Skipping DW_AT_ranges test."
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
# The .c files use __attribute__.
|
|
|
|
if [get_compiler_info] {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
if !$gcc_compiled {
|
|
|
|
verbose "Skipping DW_AT_ranges test."
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
standard_testfile dw2-ranges-base.c dw2-ranges-base-dw.S
|
|
|
|
|
|
|
|
set asm_file [standard_output_file $srcfile2]
|
|
|
|
Dwarf::assemble $asm_file {
|
|
|
|
global srcdir subdir srcfile srcfile2
|
|
|
|
declare_labels ranges_label
|
|
|
|
declare_labels L
|
|
|
|
|
|
|
|
# Find start address and length for our functions.
|
|
|
|
set main_func \
|
|
|
|
[function_range main [list ${srcdir}/${subdir}/$srcfile]]
|
|
|
|
set frame2_func \
|
|
|
|
[function_range frame2 [list ${srcdir}/${subdir}/$srcfile]]
|
|
|
|
set frame3_func \
|
|
|
|
[function_range frame3 [list ${srcdir}/${subdir}/$srcfile]]
|
|
|
|
|
|
|
|
# Very simple info for this test program. We don't care about
|
|
|
|
# this information being correct (w.r.t. funtion / argument types)
|
|
|
|
# just so long as the compilation using makes use of the
|
|
|
|
# .debug_ranges data then the test achieves its objective.
|
|
|
|
cu {} {
|
|
|
|
compile_unit {
|
|
|
|
{language @DW_LANG_C}
|
|
|
|
{name dw-ranges-base.c}
|
|
|
|
{stmt_list $L DW_FORM_sec_offset}
|
|
|
|
{ranges ${ranges_label} DW_FORM_sec_offset}
|
|
|
|
} {
|
|
|
|
subprogram {
|
|
|
|
{external 1 flag}
|
|
|
|
{name main}
|
|
|
|
}
|
|
|
|
subprogram {
|
|
|
|
{external 1 flag}
|
|
|
|
{name frame2}
|
|
|
|
}
|
|
|
|
subprogram {
|
|
|
|
{external 1 flag}
|
|
|
|
{name frame3}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
lines {version 2} L {
|
|
|
|
include_dir "${srcdir}/${subdir}"
|
|
|
|
file_name "$srcfile" 1
|
|
|
|
|
|
|
|
# Generate simple line table program. The line table
|
|
|
|
# information contained here is not correct, and we really
|
|
|
|
# don't care, just so long as each function has some line
|
|
|
|
# table data associated with it. We do make use of the fake
|
|
|
|
# line numbers that we pick here in the tests below.
|
|
|
|
program {
|
|
|
|
{DW_LNE_set_address [lindex $main_func 0]}
|
|
|
|
{DW_LNS_advance_line 10}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNS_advance_pc [lindex $main_func 1]}
|
|
|
|
{DW_LNS_advance_line 19}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNE_end_sequence}
|
|
|
|
|
|
|
|
{DW_LNE_set_address [lindex $frame2_func 0]}
|
|
|
|
{DW_LNS_advance_line 20}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNS_advance_pc [lindex $frame2_func 1]}
|
|
|
|
{DW_LNS_advance_line 29}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNE_end_sequence}
|
|
|
|
|
|
|
|
{DW_LNE_set_address [lindex $frame3_func 0]}
|
|
|
|
{DW_LNS_advance_line 30}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNS_advance_pc [lindex $frame3_func 1]}
|
|
|
|
{DW_LNS_advance_line 39}
|
|
|
|
{DW_LNS_copy}
|
|
|
|
{DW_LNE_end_sequence}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Generate ranges data. This is the point of this whole test
|
|
|
|
# file, we must have multiple bases specified, so we use a new
|
|
|
|
# base for each function.
|
|
|
|
ranges {is_64 [is_64_target]} {
|
|
|
|
ranges_label: sequence {
|
|
|
|
{base [lindex $main_func 0]}
|
|
|
|
{range 0 [lindex $main_func 1]}
|
|
|
|
{base [lindex $frame2_func 0]}
|
|
|
|
{range 0 [lindex $frame2_func 1]}
|
|
|
|
{base [lindex $frame3_func 0]}
|
|
|
|
{range 0 [lindex $frame3_func 1]}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-24 00:52:18 +08:00
|
|
|
if { [prepare_for_testing "failed to prepare" ${testfile} \
|
2015-10-16 16:08:19 +08:00
|
|
|
[list $srcfile $asm_file] {nodebug}] } {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
if ![runto_main] {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
# Make use of the line numbers we faked in the .debug_line table above.
|
|
|
|
gdb_test "info line main" \
|
|
|
|
"Line 11 of .* starts at address .* and ends at .*"
|
|
|
|
gdb_test "info line frame2" \
|
|
|
|
"Line 21 of .* starts at address .* and ends at .*"
|
|
|
|
gdb_test "info line frame3" \
|
|
|
|
"Line 31 of .* starts at address .* and ends at .*"
|
2019-11-06 00:00:26 +08:00
|
|
|
|
|
|
|
# Ensure that the line table correctly tracks the end of sequence markers.
|
|
|
|
set end_seq_count 0
|
2020-03-12 18:58:20 +08:00
|
|
|
gdb_test_multiple "maint info line-table gdb.dwarf2/dw2-ranges-base.c" \
|
2019-11-06 00:00:26 +08:00
|
|
|
"count END markers in line table" {
|
gdb: Add support for tracking the DWARF line table is-stmt field
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2019-12-31 05:04:51 +08:00
|
|
|
-re "^$decimal\[ \t\]+$decimal\[ \t\]+$hex\(\[ \t\]+Y\)?\r\n" {
|
2019-11-06 00:00:26 +08:00
|
|
|
exp_continue
|
|
|
|
}
|
gdb: Add support for tracking the DWARF line table is-stmt field
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2019-12-31 05:04:51 +08:00
|
|
|
-re "^$decimal\[ \t\]+END\[ \t\]+$hex\(\[ \t\]+Y\)?\r\n" {
|
2019-11-06 00:00:26 +08:00
|
|
|
incr end_seq_count
|
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
-re "^$gdb_prompt $" {
|
|
|
|
gdb_assert [expr $end_seq_count == 3] $gdb_test_name
|
|
|
|
}
|
|
|
|
-re ".*linetable: \\(\\(struct linetable \\*\\) 0x0\\):\r\nNo line table.\r\n" {
|
|
|
|
exp_continue
|
|
|
|
}
|
gdb: Add support for tracking the DWARF line table is-stmt field
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
2019-12-31 05:04:51 +08:00
|
|
|
-re ".*linetable: \\(\\(struct linetable \\*\\) $hex\\):\r\nINDEX\[ \t\]+LINE\[ \t\]+ADDRESS\[ \t\]+IS-STMT\r\n" {
|
2019-11-06 00:00:26 +08:00
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
}
|