aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linuxTom de Vries1-0/+8
With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into: ... (gdb) break bar_label^M Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M (gdb) continue^M Continuing.^M ^M Breakpoint 2, bar () at dw2-lines.c:29^M 29 foo (2);^M (gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\) ... The pass is incorrect because the continue lands at line 29 with "foo (2)" instead of line line 27 with "foo (1)". A minimal version is: ... $ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label" Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29. ... where: ... 000004ec <bar>: 4ec: b580 push {r7, lr} 4ee: af00 add r7, sp, #0 000004f0 <bar_label>: 4f0: 2001 movs r0, #1 4f2: f7ff fff1 bl 4d8 <foo> 000004f6 <bar_label_2>: 4f6: 2002 movs r0, #2 4f8: f7ff ffee bl 4d8 <foo> ... So, how does this happen? In short: - skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec, - thumb_analyze_prologue returns 0x4f2 (overshooting by 1 insn, PR tdep/31981), and - skip_prologue_sal decides that we're mid-line, and updates to 0x4f6. However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue use the line info to skip the prologue? The answer is that the line info starts at bar_label, not at bar. Fixing that allows us to work around PR tdep/31981. Likewise in gdb.dwarf2/dw2-line-number-zero.exp. Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to checking quality of architecture-specific prologue analysis, without being written in an architecture-specific way. If fails on arm-linux for both marm and mthumb: ... FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much) FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much) ... and passes for: - x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie} - aarch64-linux. Tested on arm-linux.
2024-04-17[gdb/testsuite] Fix end_sequence addressesTom de Vries1-2/+5
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: ... 00000000004102c4 <end_of_sequence>: 4102c4: 52800000 mov w0, #0x0 // #0 4102c8: 9100c3ff add sp, sp, #0x30 4102cc: d65f03c0 ret ... is not described by the line table: ... File name Line number Starting address View Stmt ... map-to-same-line.c 54 0x4102ac x map-to-same-line.c - 0x4102c4 ... Fix this by ending the line table at $main_end. Likewise in a few other test-cases, found using: ... $ find gdb/testsuite/ -type f \ | xargs grep -B1 DW_LNE_end_sequence \ | grep set_address \ | egrep -v "_end|_len" ... Tested on aarch64-linux.
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-01-13Use require is_c_compiler_gccTom Tromey1-4/+1
This changes some tests to use "require is_c_compiler_gcc".
2023-01-13Use require dwarf2_supportTom Tromey1-4/+1
This changes some tests to use "require dwarf2_support".
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-06-24gdb/testsuite: remove global gcc_compiled from gdb.expAndrew Burgess1-4/+1
After this commit the gcc_compiled global is no longer exported from lib/gdb.exp. In theory we could switch over all uses of gcc_compiled to instead call test_compiler_info directly, however, I have instead added a new proc to gdb.exp: 'is_c_compiler_gcc'. I've then updated the testsuite to call this proc instead of using the global. Having a new proc specifically for this task means that we have a single consistent pattern for detecting gcc. By wrapping this logic within a proc that calls test_compiler_info, rather than using the global, means that test scripts don't need to call get_compiler_info before they read the global, simply calling the new proc does everything in one go. As a result I've been able to remove the get_compiler_info calls from all the test scripts that I've touched in this commit. In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was being checked at the top of the script to decide if the whole script should be skipped or not. In these cases I've called the new proc directly and removed all uses of gcc_compiled. In other cases, e.g. most of the gdb.base scripts, there were many uses of gcc_compiled. In these cases I set a new global gcc_compiled near the top of the script, and leave the rest of the script unchanged. There should be no changes in what is tested after this commit.
2022-04-07gdb/testsuite/dwarf: simplify line number program syntaxSimon Marchi1-30/+30
By calling `uplevel $body` in the program proc (a pattern we use at many places), we can get rid of curly braces around each line number program directive. That seems like a nice small improvement to me. Change-Id: Ib327edcbffbd4c23a08614adee56c12ea25ebc0b
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-10-20[gdb/testsuite] Use $gdb_test_file_name in gdb.dwarf2Tom de Vries1-2/+2
In f.i. gdb.dwarf2/dw2-line-number-zero.exp we find: ... verbose "Skipping dw2-line-number-zero test." ... Make the skip messages use the gdb_test_file_name variable, to reduce the amount of changes that needs to be made when coping a test-case. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-10-20 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-error.exp: Use $gdb_test_file_name. * gdb.dwarf2/dw2-line-number-zero.exp: Same. * gdb.dwarf2/dw2-main-no-line-number.exp: Same. * gdb.dwarf2/dw2-ranges-base.exp: Same. * gdb.dwarf2/dw2-ranges.exp: Same. * gdb.dwarf2/dw2-vendor-extended-opcode.exp: Same. * gdb.dwarf2/var-access.exp: Same.
2020-10-17[gdb/testsuite] Remove hardcoded filenames in gdb.dwarf2/*.expTom de Vries1-1/+1
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-07-29[gdb/testsuite] Make gdb.dwarf2/dw2-line-number-zero.exp more robustTom de Vries1-2/+2
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to problems in the prologue analyzer (filed as PR26310). Make the test-case more robust by avoiding to use the prologue analyzer: ... -gdb_breakpoint "bar1" +gdb_breakpoint "$srcfile:27" ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-29 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines rather than function name.
2020-07-25[gdb/symtab] Ignore zero line table entriesTom de Vries1-0/+140
The DWARF standard states for the line register in the line number information state machine the following: ... An unsigned integer indicating a source line number. Lines are numbered beginning at 1. The compiler may emit the value 0 in cases where an instruction cannot be attributed to any source line. ... So, it's possible to have a zero line number in the DWARF line table. This is currently not handled by GDB. The zero value is read in as any other line number, but internally the zero value has a special meaning: end-of-sequence, so the line table entry ends up having a different interpretation than intended in some situations. I've created a test-case where various aspects are tested, which has these 4 interesting tests. 1. Next-step through a zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next 2. Next-step through a zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next 3. Show source location at zero-line instruction, is_stmt == 1 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 4. Show source location at zero-line instruction, is_stmt == 0 gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 And we have the following results: 8.3.1, 9.2: ... FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt field": ... PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting", master: FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3 PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3 ... The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243, where clang emits zero line numbers. The way to fix all tests is to make sure line number zero internally doesn't clash with special meaning values, and by handling it appropriately everywhere. That however looks too intrusive for the GDB 10 release. Instead, we decide to ensure defined behaviour for line number zero by ignoring it. This gives us back the test results from before commit d8cc8af6a1, fixing PR26243. We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb 10 the cost for having defined behaviour. Build and reg-tested on x86_64-linux. gdb/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line entries. gdb/testsuite/ChangeLog: 2020-07-25 Tom de Vries <tdevries@suse.de> PR symtab/26243 * gdb.dwarf2/dw2-line-number-zero.c: New test. * gdb.dwarf2/dw2-line-number-zero.exp: New file.
generated by cgit v1.1 at 2024-11-20 10:32:24 +0000