binutils-gdb/gdb/testsuite/gdb.dwarf2/dw2-inline-small-func.exp

142 lines
4.0 KiB
Plaintext
Raw Normal View History

# Copyright 2020-2022 Free Software Foundation, Inc.
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +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/>.
# Check for an issue in GDB where buildsym_compunit::record_line was
# removing duplicate line table entries, but skip_prologue_using_sal
# depends on these duplicates to spot the end of the prologue.
#
# When the de-duplication was added this regression was not spotted as
# it requires a particular combination of a (very) small function
# being inlined into an also very small outer function.
#
# This test recreates the exact combination of line table entries that
# were seen in the original test using the Dejagnu DWARF compiler.
load_lib dwarf.exp
# This test can only be run on targets which support DWARF-2 and use gas.
if {![dwarf2_support]} {
return 0
}
# The .c files use __attribute__.
if ![is_c_compiler_gcc] {
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
return 0
}
[gdb/testsuite] Remove hardcoded filenames in gdb.dwarf2/*.exp There's a common occurance in dwarf assembly test-cases, where a file test.exp contains: ... standard_testfile test.c test-dw.S ... The "test.c" arg can be abbreviated to ".c". Make standard_testfile treat args with "-" prefix the same as with "." prefix, such that we can write: ... standard_testfile .c -dw.S ... and apply this in gdb.dwarf2/*.exp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-10-17 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (standard_testfile): Also treat args starting with '-' as suffix. * gdb.dwarf2/atomic.c: Rename to ... * gdb.dwarf2/atomic-type.c: ... this. * gdb.dwarf2/dw2-ranges2.c: Rename to ... * gdb.dwarf2/dw2-ranges-2.c: ... this. * gdb.dwarf2/dw2-ranges3.c: Rename to ... * gdb.dwarf2/dw2-ranges-3.c: ... this. * gdb.dwarf2/fission-mix2.c: Rename to ... * gdb.dwarf2/fission-mix-2.c: ... this. * gdb.dwarf2/ada-linkage-name.exp: Use more suffix args for standard_testfile. * gdb.dwarf2/ada-valprint-error.exp: Same. * gdb.dwarf2/arr-stride.exp: Same. * gdb.dwarf2/arr-subrange.exp: Same. * gdb.dwarf2/atomic-type.exp: Same. * gdb.dwarf2/bad-regnum.exp: Same. * gdb.dwarf2/break-inline-psymtab.exp: Same. * gdb.dwarf2/clang-debug-names-2.exp: Same. * gdb.dwarf2/clang-debug-names.exp: Same. * gdb.dwarf2/comp-unit-lang.exp: Same. * gdb.dwarf2/corrupt.exp: Same. * gdb.dwarf2/count.exp: Same. * gdb.dwarf2/cpp-linkage-name.exp: Same. * gdb.dwarf2/data-loc.exp: Same. * gdb.dwarf2/dw2-align.exp: Same. * gdb.dwarf2/dw2-bad-elf.exp: Same. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same. * gdb.dwarf2/dw2-bad-unresolved.exp: Same. * gdb.dwarf2/dw2-case-insensitive.exp: Same. * gdb.dwarf2/dw2-cp-infcall-ref-static.exp: Same. * gdb.dwarf2/dw2-ifort-parameter.exp: Same. * gdb.dwarf2/dw2-inline-many-frames.exp: Same. * gdb.dwarf2/dw2-inline-param.exp: Same. * gdb.dwarf2/dw2-inline-small-func.exp: Same. * gdb.dwarf2/dw2-inline-stepping.exp: Same. * gdb.dwarf2/dw2-is-stmt-2.exp: Same. * gdb.dwarf2/dw2-is-stmt.exp: Same. * gdb.dwarf2/dw2-line-number-zero.exp: Same. * gdb.dwarf2/dw2-namespaceless-anonymous.exp: Same. * gdb.dwarf2/dw2-opt-structptr.exp: Same. * gdb.dwarf2/dw2-param-error.exp: Same. * gdb.dwarf2/dw2-ranges-base.exp: Same. * gdb.dwarf2/dw2-ranges.exp: Same. * gdb.dwarf2/dw2-unusual-field-names.exp: Same. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: Same. * gdb.dwarf2/dw4-sig-types.exp: Same. * gdb.dwarf2/dynarr-ptr.exp: Same. * gdb.dwarf2/enum-type.exp: Same. * gdb.dwarf2/fission-mix.exp: Same. * gdb.dwarf2/formdata16.exp: Same. * gdb.dwarf2/implptrconst.exp: Same. * gdb.dwarf2/implptrpiece.exp: Same. * gdb.dwarf2/info-locals-optimized-out.exp: Same. * gdb.dwarf2/main-subprogram.exp: Same. * gdb.dwarf2/method-ptr.exp: Same. * gdb.dwarf2/missing-sig-type.exp: Same. * gdb.dwarf2/nonvar-access.exp: Same. * gdb.dwarf2/opaque-type-lookup.exp: Same. * gdb.dwarf2/shortpiece.exp: Same. * gdb.dwarf2/staticvirtual.exp: Same. * gdb.dwarf2/subrange.exp: Same. * gdb.dwarf2/symtab-producer.exp: Same. * gdb.dwarf2/typedef-void-finish.exp: Same. * gdb.dwarf2/var-access.exp: Same. * gdb.dwarf2/variant.exp: Same. * gdb.dwarf2/void-type.exp: Same. * gdb.dwarf2/dw2-ranges-psym.exp: Same. Use main.c instead of dw2-ranges-main.c. * gdb.dwarf2/dw2-ranges-main.c: Remove.
2020-10-17 06:10:31 +08:00
standard_testfile -lbls.c .S \
.c .h
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
global srcdir subdir srcfile srcfile3 srcfile4
declare_labels lines_label callee_subprog_label
get_func_info main {debug optimize=-O1}
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
cu {} {
# It is important that the producer here be 'clang' as, at the
# time of writing this, GCC for x86-64 doesn't make use of
# skip_prologue_using_sal, while clang does.
compile_unit {
{producer "clang xxxx" }
{language @DW_LANG_C}
{name ${srcfile3}}
{low_pc 0 addr}
{stmt_list ${lines_label} DW_FORM_sec_offset}
} {
callee_subprog_label: subprogram {
{external 1 flag}
{name callee}
{inline 3 data1}
}
subprogram {
{external 1 flag}
{name main}
{low_pc $main_start addr}
{high_pc "$main_start + $main_len" addr}
} {
inlined_subroutine {
{abstract_origin %$callee_subprog_label}
{low_pc line_label_1 addr}
{high_pc line_label_2 addr}
{call_file 1 data1}
{call_line 21 data1}
}
}
}
}
lines {version 2 default_is_stmt 1} lines_label {
include_dir "${srcdir}/${subdir}"
file_name "$srcfile3" 1
file_name "$srcfile4" 1
set f1_l1 [gdb_get_line_number "caller: before call" $srcfile3]
set f1_l2 [gdb_get_line_number "caller: the call" $srcfile3]
set f1_l3 [gdb_get_line_number "caller: after call" $srcfile3]
set f2_l1 [gdb_get_line_number "callee: body" $srcfile4]
program {
DW_LNE_set_address line_label_1
line $f1_l1
DW_LNS_copy
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
line ${f1_l2}
DW_LNS_copy
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
DW_LNS_set_file 2
line ${f2_l1}
DW_LNS_copy
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
DW_LNS_negate_stmt
DW_LNS_copy
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
DW_LNS_set_file 1
DW_LNE_set_address line_label_2
line ${f1_l3}
DW_LNS_copy
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
DW_LNE_set_address line_label_3
DW_LNS_copy
DW_LNE_end_sequence
gdb: Don't remove duplicate entries from the line table In this commit: commit 8c95582da858ac981f689a6f599acacb8c5c490f Date: Mon Dec 30 21:04:51 2019 +0000 gdb: Add support for tracking the DWARF line table is-stmt field A change was made in buildsym_compunit::record_line to remove duplicate line table entries in some cases. This was an invalid change, as these duplicate line table entries are used in _some_ cases as part of prologue detection (see skip_prologue_using_sal). It might be possible to identify those line table entries that are required by skip_prologue_using_sal and only keep those duplicates around, however, I have not done this here. The original duplicate removal was done because (a) it was easy to implement, and (b) it seemed obviously harmless. As (b) is now known to be false, and implementation would be more complex, and so (a) is also false. As such, it seems better to keep all duplicates until an actual reason presents itself for why we should remove any. The original regression was spotted on RISC-V, which makes use of skip_prologue_using_sal as part of riscv_skip_prologue. Originally I created the test gdb.dwarf2/dw2-inline-small-func.exp, however, this test will not compile on RISC-V as this target doesn't support .uleb128 or .sleb128 assembler directives containing complex expressions. As a result I added the gdb.opt/inline-small-func.exp test, which exposes the bug on RISC-V, but obviously depends on the compiler to produce specific DWARF information in order to expose the bug. Still this test does ensure we always get the desired result, even if the DWARF changes. Originally the gdb.dwarf2/dw2-inline-small-func.exp test passed on x86-64 even with the duplicate line table entries incorrectly removed. The reason for this is that when a compilation unit doesn't have a 'producer' string then skip_prologue_using_sal is not used, instead the prologue is always skipped using analysis of the assembler code. However, for Clang on x86-64 skip_prologue_using_sal is used, so I modified the gdb.dwarf2/dw2-inline-small-func.exp test to include a 'producer' string that names the Clang compiler. With this done the test would fail on x86-64. One thing to note is that the gdb.opt/inline-small-func.exp test might fail on some targets. For example, if we compare sparc to risc-v by looking at sparc32_skip_prologue we see that this function doesn't use skip_prologue_using_sal, but instead uses find_pc_partial_function directly. I don't know the full history behind why the code is like it is, but it feels like sparc32_skip_prologue is an attempt to duplicate some of the functionality of skip_prologue_using_sal, but without all of the special cases. If this is true then the new test could easily fail on this target, this would suggest that sparc should consider switching to use skip_prologue_using_sal like risc-v does. gdb/ChangeLog: * buildsym.c (buildsym_compunit::record_line): Remove deduplication code. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-small-func-lbls.c: New file. * gdb.dwarf2/dw2-inline-small-func.c: New file. * gdb.dwarf2/dw2-inline-small-func.exp: New file. * gdb.dwarf2/dw2-inline-small-func.h: New file. * gdb.opt/inline-small-func.c: New file. * gdb.opt/inline-small-func.exp: New file. * gdb.opt/inline-small-func.h: New file.
2020-03-23 20:40:24 +08:00
}
}
}
if { [prepare_for_testing "failed to prepare" ${testfile} \
[list $srcfile $asm_file] {nodebug optimize=-O1}] } {
return -1
}
if ![runto_main] {
return -1
}
# Delete all breakpoints so that the output of "info breakpoints"
# below will only contain a single breakpoint.
delete_breakpoints
# Place a breakpoint within the function in the header file.
set linenum [gdb_get_line_number "callee: body" $srcfile4]
gdb_breakpoint "${srcfile4}:${linenum}"
# Check that the breakpoint was placed where we expected. It should
# appear at the requested line. When the bug in GDB was present the
# breakpoint would be placed on one of the following lines instead.
gdb_test "info breakpoints" \
".* in callee at \[^\r\n\]+${srcfile4}:${linenum}\\y.*"