2021-01-01 16:03:39 +08:00
|
|
|
# Copyright 2015-2021 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]} {
|
2020-10-20 16:20:24 +08:00
|
|
|
verbose "Skipping $gdb_test_file_name."
|
2015-10-16 16:08:19 +08:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
# The .c files use __attribute__.
|
|
|
|
if [get_compiler_info] {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
if !$gcc_compiled {
|
2020-10-20 16:20:24 +08:00
|
|
|
verbose "Skipping $gdb_test_file_name."
|
2015-10-16 16:08:19 +08:00
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2020-10-17 06:10:31 +08:00
|
|
|
standard_testfile .c -dw.S
|
2015-10-16 16:08:19 +08:00
|
|
|
|
|
|
|
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 {
|
2020-11-07 02:09:58 +08:00
|
|
|
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]
|
2015-10-16 16:08:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
[gdb/symtab] Fix line-table end-of-sequence sorting
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring
non-sensical entries that are filtered out by buildsym_compunit::record_line)
a line-table for dw2-ranges-base.c like this:
...
Line Number Statements:
[0x0000014e] Extended opcode 2: set Address to 0x4004ba
[0x00000159] Advance Line by 10 to 11
[0x0000015b] Copy
[0x0000015c] Advance PC by 12 to 0x4004c6
[0x0000015e] Extended opcode 1: End of Sequence
[0x00000161] Extended opcode 2: set Address to 0x4004ae
[0x0000016c] Advance Line by 20 to 21
[0x0000016e] Copy
[0x0000016f] Advance PC by 12 to 0x4004ba
[0x00000171] Extended opcode 1: End of Sequence
[0x00000174] Extended opcode 2: set Address to 0x4004a7
[0x0000017f] Advance Line by 30 to 31
[0x00000181] Copy
[0x00000182] Advance PC by 7 to 0x4004ae
[0x00000184] Extended opcode 1: End of Sequence
...
If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector,
we have the unsorted line table:
...
INDEX LINE ADDRESS IS-STMT
0 11 0x00000000004004ba Y
1 END 0x00000000004004c6 Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 31 0x00000000004004a7 Y
5 END 0x00000000004004ae Y
...
It contains 3 sequences, 11/END, 21/END and 31/END.
We want to sort the 3 sequences relative to each other, while sorting on
address, to get:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 END 0x00000000004004ae Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 11 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
However, if we re-enable the sorting, we have instead:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 21 0x00000000004004ae Y
2 END 0x00000000004004ae Y
3 11 0x00000000004004ba Y
4 END 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table
entries too much when sorting", that introduced sorting on address while
keeping entries with the same address in pre-sort order.
Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5
in the unsorted line table), but entry 1 does not belong in the sequence
terminated by 2.
Fix this by handling End-Of-Sequence entries in the sorting function, such
that they are sorted before other entries with the same address.
Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313,
since that's no longer necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle
End-Of-Sequence in lte_is_less_than.
* symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313
"gdb: Don't reorder line table entries too much when sorting".
gdb/testsuite/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
2020-07-06 20:28:58 +08:00
|
|
|
set prev -1
|
|
|
|
set 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" {
|
2020-03-20 21:15:08 +08:00
|
|
|
-re "^$decimal\[ \t\]+$decimal\[ \t\]+$hex\(\[ \t\]+Y\)? *\r\n" {
|
[gdb/symtab] Fix line-table end-of-sequence sorting
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring
non-sensical entries that are filtered out by buildsym_compunit::record_line)
a line-table for dw2-ranges-base.c like this:
...
Line Number Statements:
[0x0000014e] Extended opcode 2: set Address to 0x4004ba
[0x00000159] Advance Line by 10 to 11
[0x0000015b] Copy
[0x0000015c] Advance PC by 12 to 0x4004c6
[0x0000015e] Extended opcode 1: End of Sequence
[0x00000161] Extended opcode 2: set Address to 0x4004ae
[0x0000016c] Advance Line by 20 to 21
[0x0000016e] Copy
[0x0000016f] Advance PC by 12 to 0x4004ba
[0x00000171] Extended opcode 1: End of Sequence
[0x00000174] Extended opcode 2: set Address to 0x4004a7
[0x0000017f] Advance Line by 30 to 31
[0x00000181] Copy
[0x00000182] Advance PC by 7 to 0x4004ae
[0x00000184] Extended opcode 1: End of Sequence
...
If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector,
we have the unsorted line table:
...
INDEX LINE ADDRESS IS-STMT
0 11 0x00000000004004ba Y
1 END 0x00000000004004c6 Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 31 0x00000000004004a7 Y
5 END 0x00000000004004ae Y
...
It contains 3 sequences, 11/END, 21/END and 31/END.
We want to sort the 3 sequences relative to each other, while sorting on
address, to get:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 END 0x00000000004004ae Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 11 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
However, if we re-enable the sorting, we have instead:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 21 0x00000000004004ae Y
2 END 0x00000000004004ae Y
3 11 0x00000000004004ba Y
4 END 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table
entries too much when sorting", that introduced sorting on address while
keeping entries with the same address in pre-sort order.
Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5
in the unsorted line table), but entry 1 does not belong in the sequence
terminated by 2.
Fix this by handling End-Of-Sequence entries in the sorting function, such
that they are sorted before other entries with the same address.
Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313,
since that's no longer necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle
End-Of-Sequence in lte_is_less_than.
* symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313
"gdb: Don't reorder line table entries too much when sorting".
gdb/testsuite/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
2020-07-06 20:28:58 +08:00
|
|
|
if { $prev != -1 } {
|
|
|
|
gdb_assert "$prev == 1" \
|
|
|
|
"prev of normal entry at $seq_count is end marker"
|
|
|
|
}
|
|
|
|
set prev 0
|
|
|
|
incr seq_count
|
2019-11-06 00:00:26 +08:00
|
|
|
exp_continue
|
|
|
|
}
|
2020-03-20 21:15:08 +08:00
|
|
|
-re "^$decimal\[ \t\]+END\[ \t\]+$hex\(\[ \t\]+Y\)? *\r\n" {
|
[gdb/symtab] Fix line-table end-of-sequence sorting
Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring
non-sensical entries that are filtered out by buildsym_compunit::record_line)
a line-table for dw2-ranges-base.c like this:
...
Line Number Statements:
[0x0000014e] Extended opcode 2: set Address to 0x4004ba
[0x00000159] Advance Line by 10 to 11
[0x0000015b] Copy
[0x0000015c] Advance PC by 12 to 0x4004c6
[0x0000015e] Extended opcode 1: End of Sequence
[0x00000161] Extended opcode 2: set Address to 0x4004ae
[0x0000016c] Advance Line by 20 to 21
[0x0000016e] Copy
[0x0000016f] Advance PC by 12 to 0x4004ba
[0x00000171] Extended opcode 1: End of Sequence
[0x00000174] Extended opcode 2: set Address to 0x4004a7
[0x0000017f] Advance Line by 30 to 31
[0x00000181] Copy
[0x00000182] Advance PC by 7 to 0x4004ae
[0x00000184] Extended opcode 1: End of Sequence
...
If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector,
we have the unsorted line table:
...
INDEX LINE ADDRESS IS-STMT
0 11 0x00000000004004ba Y
1 END 0x00000000004004c6 Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 31 0x00000000004004a7 Y
5 END 0x00000000004004ae Y
...
It contains 3 sequences, 11/END, 21/END and 31/END.
We want to sort the 3 sequences relative to each other, while sorting on
address, to get:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 END 0x00000000004004ae Y
2 21 0x00000000004004ae Y
3 END 0x00000000004004ba Y
4 11 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
However, if we re-enable the sorting, we have instead:
...
INDEX LINE ADDRESS IS-STMT
0 31 0x00000000004004a7 Y
1 21 0x00000000004004ae Y
2 END 0x00000000004004ae Y
3 11 0x00000000004004ba Y
4 END 0x00000000004004ba Y
5 END 0x00000000004004c6 Y
...
This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table
entries too much when sorting", that introduced sorting on address while
keeping entries with the same address in pre-sort order.
Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5
in the unsorted line table), but entry 1 does not belong in the sequence
terminated by 2.
Fix this by handling End-Of-Sequence entries in the sorting function, such
that they are sorted before other entries with the same address.
Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313,
since that's no longer necessary.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle
End-Of-Sequence in lte_is_less_than.
* symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313
"gdb: Don't reorder line table entries too much when sorting".
gdb/testsuite/ChangeLog:
2020-07-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
2020-07-06 20:28:58 +08:00
|
|
|
if { $prev != -1 } {
|
|
|
|
gdb_assert "$prev == 0" \
|
|
|
|
"prev of end marker at $seq_count is normal entry"
|
|
|
|
}
|
|
|
|
set prev 1
|
|
|
|
incr seq_count
|
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
|
|
|
|
}
|
2020-03-20 21:15:08 +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
|
|
|
|
}
|
|
|
|
}
|