* [PATCH 1/6] gdb/testsuite/dwarf: remove two unused variables
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-07 13:51 ` Tom Tromey
2022-04-07 1:51 ` [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax Simon Marchi
` (4 subsequent siblings)
5 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches
These variables seem to be unused, remove them.
Change-Id: I7d613d9d35735930ee78b2c348943c73a702afbb
---
gdb/testsuite/lib/dwarf.exp | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index ed7ad3831809..3d88003ccb09 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -569,12 +569,6 @@ namespace eval Dwarf {
# Current .debug_line unit count.
variable _line_count
- # Whether a file_name entry was seen.
- variable _line_saw_file
-
- # Whether a line table program has been seen.
- variable _line_saw_program
-
# A Label for line table header generation.
variable _line_header_end_label
@@ -2178,11 +2172,9 @@ namespace eval Dwarf {
proc lines {options label body} {
variable _line_count
- variable _line_saw_file
variable _line_include_dirs
variable _line_file_names
variable _line_header_finalized
- variable _line_saw_program
variable _line_header_end_label
variable _line_unit_version
variable _line_is_64
@@ -2192,8 +2184,6 @@ namespace eval Dwarf {
set _line_is_64 0
set _line_unit_version 4
set _unit_addr_size default
- set _line_saw_program 0
- set _line_saw_file 0
set _line_include_dirs {}
set _line_file_names {}
set _line_header_finalized 0
@@ -2295,9 +2285,6 @@ namespace eval Dwarf {
proc file_name {filename diridx} {
variable _line_file_names
lappend _line_file_names $filename $diridx
-
- variable _line_saw_file 1
- set _line_saw_file 1
}
proc _line_finalize_header {} {
@@ -2424,11 +2411,9 @@ namespace eval Dwarf {
}
proc program {statements} {
- variable _line_saw_program
variable _line_header_end_label
variable _line
- set _line_saw_program 1
set _line 1
@@ -2872,8 +2857,6 @@ namespace eval Dwarf {
variable _strings
variable _cu_count
variable _line_count
- variable _line_saw_file
- variable _line_saw_program
variable _line_header_end_label
variable _debug_ranges_64_bit
variable _debug_addr_index
@@ -2891,8 +2874,6 @@ namespace eval Dwarf {
_empty_array _strings
set _line_count 0
- set _line_saw_file 0
- set _line_saw_program 0
set _debug_ranges_64_bit [is_64_target]
set _debug_addr_index 0
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
2022-04-07 1:51 ` [PATCH 1/6] gdb/testsuite/dwarf: remove two unused variables Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-07 13:52 ` Tom Tromey
2022-04-07 1:51 ` [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5 Simon Marchi
` (3 subsequent siblings)
5 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches
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
---
.../gdb.base/until-trailing-insns.exp | 58 +++---
gdb/testsuite/gdb.dwarf2/dw2-bad-elf.exp | 28 +--
.../gdb.dwarf2/dw2-disasm-over-non-stmt.exp | 56 +++---
| 70 ++++----
| 66 +++----
| 66 +++----
.../gdb.dwarf2/dw2-inline-many-frames.exp | 168 +++++++++---------
.../gdb.dwarf2/dw2-inline-small-func.exp | 34 ++--
.../gdb.dwarf2/dw2-inline-stepping.exp | 46 ++---
.../dw2-inline-with-lexical-scope.exp | 28 +--
gdb/testsuite/gdb.dwarf2/dw2-is-stmt-2.exp | 156 ++++++++--------
gdb/testsuite/gdb.dwarf2/dw2-is-stmt.exp | 58 +++---
.../gdb.dwarf2/dw2-line-number-zero.exp | 60 +++----
gdb/testsuite/gdb.dwarf2/dw2-lines.exp | 28 +--
.../dw2-out-of-range-end-of-seq.exp | 20 +--
gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp | 34 ++--
gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp | 46 ++---
gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp | 120 ++++++-------
.../dw2-step-out-of-function-no-stmt.exp | 36 ++--
.../gdb.dwarf2/dw2-symtab-includes-lookup.exp | 2 +-
.../gdb.dwarf2/dw2-symtab-includes.exp | 2 +-
.../gdb.dwarf2/dw2-vendor-extended-opcode.exp | 14 +-
gdb/testsuite/gdb.dwarf2/fission-multi-cu.exp | 64 +++----
.../gdb.dwarf2/imported-unit-bp.exp.tcl | 48 ++---
.../locexpr-data-member-location.exp | 50 +++---
gdb/testsuite/lib/dwarf.exp | 6 +-
26 files changed, 681 insertions(+), 683 deletions(-)
diff --git a/gdb/testsuite/gdb.base/until-trailing-insns.exp b/gdb/testsuite/gdb.base/until-trailing-insns.exp
index e87f4a317e7e..ca5b388c0a66 100644
--- a/gdb/testsuite/gdb.base/until-trailing-insns.exp
+++ b/gdb/testsuite/gdb.base/until-trailing-insns.exp
@@ -135,35 +135,35 @@ Dwarf::assemble $asm_file {
# of adding some !is_stmt at the end of a loop line, making until
# not work properly.
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "TAG: main prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address loop_start}
- {line [gdb_get_line_number "TAG: loop line"]}
- {DW_LNS_copy}
- {DW_LNE_set_address loop_condition}
- {line [gdb_get_line_number "TAG: loop line"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNE_set_address loop_code}
- {line [gdb_get_line_number "TAG: loop code"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNE_set_address loop_increment}
- {line [gdb_get_line_number "TAG: loop line"]}
- {DW_LNS_copy}
- {DW_LNE_set_address loop_jump}
- {line [gdb_get_line_number "TAG: loop line"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNE_set_address main_return}
- {line [gdb_get_line_number "TAG: main return"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNE_set_address $main_end}
- {line [expr [gdb_get_line_number "TAG: main return"] + 1]}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "TAG: main prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address loop_start
+ line [gdb_get_line_number "TAG: loop line"]
+ DW_LNS_copy
+ DW_LNE_set_address loop_condition
+ line [gdb_get_line_number "TAG: loop line"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNE_set_address loop_code
+ line [gdb_get_line_number "TAG: loop code"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNE_set_address loop_increment
+ line [gdb_get_line_number "TAG: loop line"]
+ DW_LNS_copy
+ DW_LNE_set_address loop_jump
+ line [gdb_get_line_number "TAG: loop line"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNE_set_address main_return
+ line [gdb_get_line_number "TAG: main return"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNE_set_address $main_end
+ line [expr [gdb_get_line_number "TAG: main return"] + 1]
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-bad-elf.exp b/gdb/testsuite/gdb.dwarf2/dw2-bad-elf.exp
index 0adff2868eb0..7b71ed1155ef 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-bad-elf.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-bad-elf.exp
@@ -127,13 +127,13 @@ Dwarf::assemble $asm_file {
# Line data doens't need to be correct, just present.
program {
- {DW_LNE_set_address [lindex $main_result 0]}
- {DW_LNS_advance_line 10}
- {DW_LNS_copy}
- {DW_LNS_advance_pc [lindex $main_result 1]}
- {DW_LNS_advance_line 19}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address [lindex $main_result 0]
+ DW_LNS_advance_line 10
+ DW_LNS_copy
+ DW_LNS_advance_pc [lindex $main_result 1]
+ DW_LNS_advance_line 19
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
@@ -143,13 +143,13 @@ Dwarf::assemble $asm_file {
# Line data doens't need to be correct, just present.
program {
- {DW_LNE_set_address some_func}
- {DW_LNS_advance_line 5}
- {DW_LNS_copy}
- {DW_LNS_advance_pc 64}
- {DW_LNS_advance_line 8}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address some_func
+ DW_LNS_advance_line 5
+ DW_LNS_copy
+ DW_LNS_advance_pc 64
+ DW_LNS_advance_line 8
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-disasm-over-non-stmt.exp b/gdb/testsuite/gdb.dwarf2/dw2-disasm-over-non-stmt.exp
index ea679c3adc18..5311dd61a4c7 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-disasm-over-non-stmt.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-disasm-over-non-stmt.exp
@@ -68,34 +68,34 @@ Dwarf::assemble $asm_file {
file_name "$srcfile3" 1
program {
- {DW_LNE_set_address $main_start}
- {DW_LNS_advance_line 15}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_5}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_6}
- {DW_LNS_advance_line 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address $main_end}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ DW_LNS_advance_line 15
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_5
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_6
+ DW_LNS_advance_line 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address $main_end
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
}
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
index 4ee7433f249d..19f06adef7b2 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-1.exp
@@ -119,41 +119,41 @@ proc do_test { start_label func_name tag } {
file_name "$srcfile4" 1
program {
- {DW_LNE_set_address line_label_1}
- {DW_LNS_advance_line 15}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_set_file 2}
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 4}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_advance_line -4}
- {DW_LNS_set_file 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNS_set_file 2}
- {DW_LNE_set_address line_label_5}
- {DW_LNS_advance_line 5}
- {DW_LNS_copy}
-
- {DW_LNS_negate_stmt}
- {DW_LNS_set_file 1}
- {DW_LNE_set_address line_label_6}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_7}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address line_label_1
+ DW_LNS_advance_line 15
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_set_file 2
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 4
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_advance_line -4
+ DW_LNS_set_file 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNS_set_file 2
+ DW_LNE_set_address line_label_5
+ DW_LNS_advance_line 5
+ DW_LNS_copy
+
+ DW_LNS_negate_stmt
+ DW_LNS_set_file 1
+ DW_LNE_set_address line_label_6
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_7
+ DW_LNE_end_sequence
}
}
}
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
index a8014489d9d3..198f35539979 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-2.exp
@@ -109,39 +109,39 @@ Dwarf::assemble $asm_file {
file_name "$srcfile4" 1
program {
- {DW_LNE_set_address line_label_1}
- {DW_LNS_advance_line 15}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_set_file 2}
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 4}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_advance_line -4}
- {DW_LNS_set_file 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_5}
- {DW_LNS_advance_line 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_6}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_7}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address line_label_1
+ DW_LNS_advance_line 15
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_set_file 2
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 4
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_advance_line -4
+ DW_LNS_set_file 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_5
+ DW_LNS_advance_line 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_6
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_7
+ DW_LNE_end_sequence
}
}
}
--git a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
index 8f36e4f52195..68261aa78b0a 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-header-3.exp
@@ -98,39 +98,39 @@ Dwarf::assemble $asm_file {
file_name "$srcfile4" 1
program {
- {DW_LNE_set_address line_label_1}
- {DW_LNS_advance_line 15}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_set_file 2}
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 4}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNS_advance_line -4}
- {DW_LNS_set_file 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_5}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_6}
- {DW_LNS_advance_line 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_7}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address line_label_1
+ DW_LNS_advance_line 15
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_set_file 2
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 4
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNS_advance_line -4
+ DW_LNS_set_file 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_5
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_6
+ DW_LNS_advance_line 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_7
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-inline-many-frames.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-many-frames.exp
index 483b197448c6..9055244979db 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-many-frames.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-many-frames.exp
@@ -187,95 +187,95 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "main set global_var"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "main call aaa"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "aaa return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "bbb return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "ccc return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label3}
- {line [gdb_get_line_number "main end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $main_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "main set global_var"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "main call aaa"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "aaa return"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "bbb return"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "ccc return"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label3
+ line [gdb_get_line_number "main end"]
+ DW_LNS_copy
+ DW_LNE_set_address $main_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address $ddd_start}
- {line [gdb_get_line_number "ddd prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address ddd_label}
- {line [gdb_get_line_number "ddd return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address ddd_label2}
- {line [gdb_get_line_number "ddd end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $ddd_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $ddd_start
+ line [gdb_get_line_number "ddd prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address ddd_label
+ line [gdb_get_line_number "ddd return"]
+ DW_LNS_copy
+ DW_LNE_set_address ddd_label2
+ line [gdb_get_line_number "ddd end"]
+ DW_LNS_copy
+ DW_LNE_set_address $ddd_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address $eee_start}
- {line [gdb_get_line_number "eee prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address eee_label}
- {line [gdb_get_line_number "eee return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address eee_label2}
- {line [gdb_get_line_number "eee end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $eee_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $eee_start
+ line [gdb_get_line_number "eee prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address eee_label
+ line [gdb_get_line_number "eee return"]
+ DW_LNS_copy
+ DW_LNE_set_address eee_label2
+ line [gdb_get_line_number "eee end"]
+ DW_LNS_copy
+ DW_LNE_set_address $eee_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address $fff_start}
- {line [gdb_get_line_number "fff prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address fff_label}
- {line [gdb_get_line_number "fff return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address fff_label}
- {line [gdb_get_line_number "ggg return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address fff_label}
- {line [gdb_get_line_number "hhh return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address fff_label}
- {line [gdb_get_line_number "iii return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address fff_label2}
- {line [gdb_get_line_number "fff end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $fff_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $fff_start
+ line [gdb_get_line_number "fff prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address fff_label
+ line [gdb_get_line_number "fff return"]
+ DW_LNS_copy
+ DW_LNE_set_address fff_label
+ line [gdb_get_line_number "ggg return"]
+ DW_LNS_copy
+ DW_LNE_set_address fff_label
+ line [gdb_get_line_number "hhh return"]
+ DW_LNS_copy
+ DW_LNE_set_address fff_label
+ line [gdb_get_line_number "iii return"]
+ DW_LNS_copy
+ DW_LNE_set_address fff_label2
+ line [gdb_get_line_number "fff end"]
+ DW_LNS_copy
+ DW_LNE_set_address $fff_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address $jjj_start}
- {line [gdb_get_line_number "jjj prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address jjj_label}
- {line [gdb_get_line_number "jjj return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address jjj_label2}
- {line [gdb_get_line_number "jjj end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $jjj_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $jjj_start
+ line [gdb_get_line_number "jjj prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address jjj_label
+ line [gdb_get_line_number "jjj return"]
+ DW_LNS_copy
+ DW_LNE_set_address jjj_label2
+ line [gdb_get_line_number "jjj end"]
+ DW_LNS_copy
+ DW_LNE_set_address $jjj_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address $kkk_start}
- {line [gdb_get_line_number "kkk prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address kkk_label}
- {line [gdb_get_line_number "kkk return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $kkk_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $kkk_start
+ line [gdb_get_line_number "kkk prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address kkk_label
+ line [gdb_get_line_number "kkk return"]
+ DW_LNS_copy
+ DW_LNE_set_address $kkk_end
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-inline-small-func.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-small-func.exp
index c480422b7554..05286ad6d2fb 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-small-func.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-small-func.exp
@@ -94,28 +94,28 @@ Dwarf::assemble $asm_file {
set f2_l1 [gdb_get_line_number "callee: body" $srcfile4]
program {
- {DW_LNE_set_address line_label_1}
- {line $f1_l1}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_1
+ line $f1_l1
+ DW_LNS_copy
- {line ${f1_l2}}
- {DW_LNS_copy}
+ line ${f1_l2}
+ DW_LNS_copy
- {DW_LNS_set_file 2}
- {line ${f2_l1}}
- {DW_LNS_copy}
+ DW_LNS_set_file 2
+ line ${f2_l1}
+ DW_LNS_copy
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
+ DW_LNS_negate_stmt
+ DW_LNS_copy
- {DW_LNS_set_file 1}
- {DW_LNE_set_address line_label_2}
- {line ${f1_l3}}
- {DW_LNS_copy}
+ DW_LNS_set_file 1
+ DW_LNE_set_address line_label_2
+ line ${f1_l3}
+ DW_LNS_copy
- {DW_LNE_set_address line_label_3}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address line_label_3
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-inline-stepping.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-stepping.exp
index aafca3015e67..bd90715c1982 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-stepping.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-stepping.exp
@@ -94,29 +94,29 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "main set global_var"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "main call foo"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "foo call bar"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $main_end}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $bar_start}
- {line [gdb_get_line_number "bar prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address bar_label}
- {line [gdb_get_line_number "bar return global_var"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $bar_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "main set global_var"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "main call foo"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "foo call bar"]
+ DW_LNS_copy
+ DW_LNE_set_address $main_end
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $bar_start
+ line [gdb_get_line_number "bar prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address bar_label
+ line [gdb_get_line_number "bar return global_var"]
+ DW_LNS_copy
+ DW_LNE_set_address $bar_end
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-inline-with-lexical-scope.exp b/gdb/testsuite/gdb.dwarf2/dw2-inline-with-lexical-scope.exp
index 485f3aef9567..61fd5d4fed82 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-inline-with-lexical-scope.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-inline-with-lexical-scope.exp
@@ -110,20 +110,20 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "func call"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "func end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "main end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $main_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "func call"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "func end"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "main end"]
+ DW_LNS_copy
+ DW_LNE_set_address $main_end
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-is-stmt-2.exp b/gdb/testsuite/gdb.dwarf2/dw2-is-stmt-2.exp
index 3ec9f8071604..239f5f1d9e96 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-is-stmt-2.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-is-stmt-2.exp
@@ -68,84 +68,84 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address main}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_0}
- {line [gdb_get_line_number "main start"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_1}
- {line [gdb_get_line_number "Line 1"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_3}
- {line [gdb_get_line_number "Line 2"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {line [gdb_get_line_number "Line 1"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_5}
- {line [gdb_get_line_number "Line 3"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_6}
- {line [gdb_get_line_number "Line 4"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_7}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_8}
- {line [gdb_get_line_number "Line 2"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_9}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_10}
- {line [gdb_get_line_number "Line 3"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_11}
- {line [gdb_get_line_number "Line 5"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_12}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_13}
- {line [gdb_get_line_number "Line 3"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_14}
- {line [gdb_get_line_number "Line 4"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_15}
- {line [gdb_get_line_number "Line 5"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_16}
- {line [gdb_get_line_number "main end"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address ${main_end}}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address main
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_0
+ line [gdb_get_line_number "main start"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_1
+ line [gdb_get_line_number "Line 1"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_3
+ line [gdb_get_line_number "Line 2"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ line [gdb_get_line_number "Line 1"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_5
+ line [gdb_get_line_number "Line 3"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_6
+ line [gdb_get_line_number "Line 4"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_7
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_8
+ line [gdb_get_line_number "Line 2"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_9
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_10
+ line [gdb_get_line_number "Line 3"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_11
+ line [gdb_get_line_number "Line 5"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_12
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_13
+ line [gdb_get_line_number "Line 3"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_14
+ line [gdb_get_line_number "Line 4"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_15
+ line [gdb_get_line_number "Line 5"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_16
+ line [gdb_get_line_number "main end"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address ${main_end}
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-is-stmt.exp b/gdb/testsuite/gdb.dwarf2/dw2-is-stmt.exp
index 9a9fc8cca646..c449757becb4 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-is-stmt.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-is-stmt.exp
@@ -68,35 +68,35 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address main}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_1}
- {line [gdb_get_line_number "main, set var to 99"]}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {line [gdb_get_line_number "main, set var to 0"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_3}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_5}
- {line [gdb_get_line_number "main end"]}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
-
- {DW_LNE_set_address ${main_end}}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address main
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_1
+ line [gdb_get_line_number "main, set var to 99"]
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ line [gdb_get_line_number "main, set var to 0"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_3
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_5
+ line [gdb_get_line_number "main end"]
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+
+ DW_LNE_set_address ${main_end}
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp b/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp
index ec15694bb583..0c5eed9814f4 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-line-number-zero.exp
@@ -62,46 +62,46 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address bar1_label}
- {line 27}
- {DW_LNS_copy}
+ DW_LNE_set_address bar1_label
+ line 27
+ DW_LNS_copy
- {DW_LNE_set_address bar1_label_2}
- {line 29}
- {DW_LNS_copy}
+ DW_LNE_set_address bar1_label_2
+ line 29
+ DW_LNS_copy
- {DW_LNE_set_address bar1_label_3}
- {line 0}
- {DW_LNS_copy}
+ DW_LNE_set_address bar1_label_3
+ line 0
+ DW_LNS_copy
- {DW_LNE_set_address bar1_label_4}
- {line 33}
- {DW_LNS_copy}
+ DW_LNE_set_address bar1_label_4
+ line 33
+ DW_LNS_copy
- {DW_LNE_set_address bar1_label_5}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address bar1_label_5
+ DW_LNE_end_sequence
- {DW_LNE_set_address bar2_label}
- {line 41}
- {DW_LNS_copy}
+ DW_LNE_set_address bar2_label
+ line 41
+ DW_LNS_copy
- {DW_LNE_set_address bar2_label_2}
- {line 43}
- {DW_LNS_copy}
+ DW_LNE_set_address bar2_label_2
+ line 43
+ DW_LNS_copy
- {DW_LNE_set_address bar2_label_3}
- {line 0}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNS_negate_stmt}
+ DW_LNE_set_address bar2_label_3
+ line 0
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNS_negate_stmt
- {DW_LNE_set_address bar2_label_4}
- {line 47}
- {DW_LNS_copy}
+ DW_LNE_set_address bar2_label_4
+ line 47
+ DW_LNS_copy
- {DW_LNE_set_address bar2_label_5}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address bar2_label_5
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-lines.exp b/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
index c1be18aa88cf..e36064460fd3 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
@@ -83,24 +83,24 @@ proc test_1 { _cv _cdw64 _lv _ldw64 {_string_form ""}} {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address bar_label}
- {line [line_for bar_label]}
- {DW_LNS_copy}
+ DW_LNE_set_address bar_label
+ line [line_for bar_label]
+ DW_LNS_copy
- {DW_LNE_set_address bar_label_2}
- {line [line_for bar_label_2]}
- {DW_LNS_copy}
+ DW_LNE_set_address bar_label_2
+ line [line_for bar_label_2]
+ DW_LNS_copy
- {DW_LNE_set_address bar_label_3}
- {line [line_for bar_label_3]}
- {DW_LNS_copy}
+ DW_LNE_set_address bar_label_3
+ line [line_for bar_label_3]
+ DW_LNS_copy
- {DW_LNE_set_address bar_label_4}
- {line [line_for bar_label_4]}
- {DW_LNS_copy}
+ DW_LNE_set_address bar_label_4
+ line [line_for bar_label_4]
+ DW_LNS_copy
- {DW_LNE_set_address bar_label_5}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address bar_label_5
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp b/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
index 23df111e73ad..b8da03ddb3d9 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-out-of-range-end-of-seq.exp
@@ -58,19 +58,19 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address main_label}
- {line 1}
- {DW_LNS_copy}
+ DW_LNE_set_address main_label
+ line 1
+ DW_LNS_copy
- {DW_LNS_advance_pc 1}
- {DW_LNE_end_sequence}
+ DW_LNS_advance_pc 1
+ DW_LNE_end_sequence
- {DW_LNE_set_address 0}
- {line 2}
- {DW_LNS_copy}
+ DW_LNE_set_address 0
+ line 2
+ DW_LNS_copy
- {DW_LNS_advance_pc 1}
- {DW_LNE_end_sequence}
+ DW_LNS_advance_pc 1
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp b/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
index b5f8bcc4b505..7fd1bd781328 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
@@ -52,28 +52,28 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "main assign m"]}
- {DW_LNS_copy}
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "main assign m"]
+ DW_LNS_copy
- {DW_LNE_set_address main_assign_n}
- {line [gdb_get_line_number "main assign n"]}
- {DW_LNS_copy}
+ DW_LNE_set_address main_assign_n
+ line [gdb_get_line_number "main assign n"]
+ DW_LNS_copy
- {DW_LNE_set_address main_end_prologue}
- {line [gdb_get_line_number "main assign o"]}
- {DW_LNS_set_prologue_end}
- {DW_LNS_copy}
+ DW_LNE_set_address main_end_prologue
+ line [gdb_get_line_number "main assign o"]
+ DW_LNS_set_prologue_end
+ DW_LNS_copy
- {DW_LNE_set_address main_end}
- {line [gdb_get_line_number "main end"]}
- {DW_LNS_copy}
+ DW_LNE_set_address main_end
+ line [gdb_get_line_number "main end"]
+ DW_LNS_copy
- {DW_LNE_end_sequence}
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp b/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp
index ec31f1f9d234..17530c8cc4b9 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-base.exp
@@ -84,29 +84,29 @@ Dwarf::assemble $asm_file {
# 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}
+ 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
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp b/gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp
index b6077e0c6760..aa95dae6bfcd 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-func.exp
@@ -133,66 +133,66 @@ proc do_test {suffix} {
# Generate a line table program. An attempt was made to make it
# reasonably accurate as it made debugging the test case easier.
program {
- {DW_LNE_set_address $main_start}
- {line [gdb_get_line_number "main prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label}
- {line [gdb_get_line_number "main foo call"]}
- {DW_LNS_copy}
- {DW_LNE_set_address main_label2}
- {line [gdb_get_line_number "main return"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $main_end}
- {line [expr [gdb_get_line_number "main end"] + 1]}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $foo_start}
- {line [gdb_get_line_number "foo prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_label}
- {line [gdb_get_line_number "foo bar call"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_label2}
- {line [gdb_get_line_number "foo foo_cold call"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_label3}
- {line [gdb_get_line_number "foo end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $foo_end}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $bar_start}
- {line [gdb_get_line_number "bar end"]}
- {DW_LNS_copy}
- {DW_LNS_advance_pc $bar_len}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $baz_start}
- {line [gdb_get_line_number "baz end"]}
- {DW_LNS_copy}
- {DW_LNS_advance_pc $baz_len}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $foo_cold_start}
- {line [gdb_get_line_number "foo_cold prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_cold_label}
- {line [gdb_get_line_number "foo_cold baz call"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_cold_label2}
- {line [gdb_get_line_number "foo_cold end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $foo_cold_end}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ line [gdb_get_line_number "main prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label
+ line [gdb_get_line_number "main foo call"]
+ DW_LNS_copy
+ DW_LNE_set_address main_label2
+ line [gdb_get_line_number "main return"]
+ DW_LNS_copy
+ DW_LNE_set_address $main_end
+ line [expr [gdb_get_line_number "main end"] + 1]
+ DW_LNS_copy
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $foo_start
+ line [gdb_get_line_number "foo prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_label
+ line [gdb_get_line_number "foo bar call"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_label2
+ line [gdb_get_line_number "foo foo_cold call"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_label3
+ line [gdb_get_line_number "foo end"]
+ DW_LNS_copy
+ DW_LNE_set_address $foo_end
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $bar_start
+ line [gdb_get_line_number "bar end"]
+ DW_LNS_copy
+ DW_LNS_advance_pc $bar_len
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $baz_start
+ line [gdb_get_line_number "baz end"]
+ DW_LNS_copy
+ DW_LNS_advance_pc $baz_len
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $foo_cold_start
+ line [gdb_get_line_number "foo_cold prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_cold_label
+ line [gdb_get_line_number "foo_cold baz call"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_cold_label2
+ line [gdb_get_line_number "foo_cold end"]
+ DW_LNS_copy
+ DW_LNE_set_address $foo_cold_end
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp b/gdb/testsuite/gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
index ad4a5f553e61..29e6858e04b9 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp
@@ -79,29 +79,29 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address bar_label}
- {line 26}
- {DW_LNS_copy}
+ DW_LNE_set_address bar_label
+ line 26
+ DW_LNS_copy
- {DW_LNE_set_address $bar_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $bar_end
+ DW_LNE_end_sequence
- {DW_LNE_set_address main_label}
- {line 32}
- {DW_LNS_copy}
+ DW_LNE_set_address main_label
+ line 32
+ DW_LNS_copy
- {DW_LNE_set_address main_label_2}
- {line 36}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
- {DW_LNS_negate_stmt}
+ DW_LNE_set_address main_label_2
+ line 36
+ DW_LNS_negate_stmt
+ DW_LNS_copy
+ DW_LNS_negate_stmt
- {DW_LNE_set_address main_label_3}
- {line 36}
- {DW_LNS_copy}
+ DW_LNE_set_address main_label_3
+ line 36
+ DW_LNS_copy
- {DW_LNE_set_address $main_end}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_end
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes-lookup.exp b/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes-lookup.exp
index feab51ad13fd..0390d36f74e1 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes-lookup.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes-lookup.exp
@@ -77,7 +77,7 @@ Dwarf::assemble $asm_file {
include_dir "${srcdir}/${subdir}"
file_name "dw2-symtab-includes.h" 1
program {
- {DW_LNS_advance_line 1}
+ DW_LNS_advance_line 1
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes.exp b/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes.exp
index e5c3342cf816..6c6d5fe46b4b 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-symtab-includes.exp
@@ -51,7 +51,7 @@ Dwarf::assemble $asm_file {
include_dir "${srcdir}/${subdir}"
file_name "dw2-symtab-includes.h" 1
program {
- {DW_LNS_advance_line 1}
+ DW_LNS_advance_line 1
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-vendor-extended-opcode.exp b/gdb/testsuite/gdb.dwarf2/dw2-vendor-extended-opcode.exp
index 86b5cc69e2ee..de8c82bb40ca 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-vendor-extended-opcode.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-vendor-extended-opcode.exp
@@ -57,14 +57,14 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address main_label}
- {line 27}
- {DW_LNE_user 1 $DW_LNE_lo_usr}
- {DW_LNE_user 2 $DW_LNE_hi_usr}
- {DW_LNS_copy}
+ DW_LNE_set_address main_label
+ line 27
+ DW_LNE_user 1 $DW_LNE_lo_usr
+ DW_LNE_user 2 $DW_LNE_hi_usr
+ DW_LNS_copy
- {DW_LNE_set_address main_label_2}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address main_label_2
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/fission-multi-cu.exp b/gdb/testsuite/gdb.dwarf2/fission-multi-cu.exp
index 9baa67ce7a34..62bffdf709d2 100644
--- a/gdb/testsuite/gdb.dwarf2/fission-multi-cu.exp
+++ b/gdb/testsuite/gdb.dwarf2/fission-multi-cu.exp
@@ -88,18 +88,18 @@ Dwarf::assemble $asm_file_1 {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $func_start}
- {DW_LNS_advance_line 24}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_4}
- {DW_LNS_advance_line 3}
- {DW_LNS_copy}
-
- {DW_LNE_set_address $func_end}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $func_start
+ DW_LNS_advance_line 24
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_4
+ DW_LNS_advance_line 3
+ DW_LNS_copy
+
+ DW_LNE_set_address $func_end
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
@@ -164,26 +164,26 @@ Dwarf::assemble $asm_file_2 {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address $main_start}
- {DW_LNS_advance_line 32}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_1}
- {DW_LNS_advance_line 3}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_2}
- {DW_LNS_advance_line 2}
- {DW_LNS_copy}
-
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 2}
- {DW_LNS_copy}
-
- {DW_LNE_set_address $main_end}
- {DW_LNS_advance_line 2}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $main_start
+ DW_LNS_advance_line 32
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_1
+ DW_LNS_advance_line 3
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_2
+ DW_LNS_advance_line 2
+ DW_LNS_copy
+
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 2
+ DW_LNS_copy
+
+ DW_LNE_set_address $main_end
+ DW_LNS_advance_line 2
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
index 4d95400cacab..fe92c530888d 100644
--- a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
+++ b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
@@ -83,37 +83,37 @@ Dwarf::assemble $asm_file {
file_name "$srcfile" 1
program {
- {DW_LNE_set_address line_label_1}
- {DW_LNS_advance_line 15}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_1
+ DW_LNS_advance_line 15
+ DW_LNS_copy
- {DW_LNE_set_address line_label_2}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_2
+ DW_LNS_advance_line 1
+ DW_LNS_copy
- {DW_LNE_set_address line_label_3}
- {DW_LNS_advance_line 4}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_3
+ DW_LNS_advance_line 4
+ DW_LNS_copy
- {DW_LNE_set_address line_label_4}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_4
+ DW_LNS_advance_line 1
+ DW_LNS_copy
- {DW_LNS_advance_line -4}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
+ DW_LNS_advance_line -4
+ DW_LNS_negate_stmt
+ DW_LNS_copy
- {DW_LNE_set_address line_label_5}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_5
+ DW_LNS_advance_line 1
+ DW_LNS_copy
- {DW_LNE_set_address line_label_6}
- {DW_LNS_advance_line 1}
- {DW_LNS_negate_stmt}
- {DW_LNS_copy}
+ DW_LNE_set_address line_label_6
+ DW_LNS_advance_line 1
+ DW_LNS_negate_stmt
+ DW_LNS_copy
- {DW_LNE_set_address line_label_7}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address line_label_7
+ DW_LNE_end_sequence
}
}
}
diff --git a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
index a0831082f095..67e96fb1128a 100644
--- a/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
+++ b/gdb/testsuite/gdb.dwarf2/locexpr-data-member-location.exp
@@ -267,31 +267,31 @@ Dwarf::assemble ${asm_file} {
# Generate a line table program.
program {
- {DW_LNE_set_address $foo_start}
- {line [gdb_get_line_number "foo prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address foo_label}
- {line [gdb_get_line_number "foo return"]}
- {DW_LNS_copy}
- {line [gdb_get_line_number "foo end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $foo_end}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
-
- {DW_LNE_set_address $bar_start}
- {line [gdb_get_line_number "bar prologue"]}
- {DW_LNS_copy}
- {DW_LNE_set_address bar_label}
- {line [gdb_get_line_number "bar return"]}
- {DW_LNS_copy}
- {line [gdb_get_line_number "bar end"]}
- {DW_LNS_copy}
- {DW_LNE_set_address $bar_end}
- {DW_LNS_advance_line 1}
- {DW_LNS_copy}
- {DW_LNE_end_sequence}
+ DW_LNE_set_address $foo_start
+ line [gdb_get_line_number "foo prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address foo_label
+ line [gdb_get_line_number "foo return"]
+ DW_LNS_copy
+ line [gdb_get_line_number "foo end"]
+ DW_LNS_copy
+ DW_LNE_set_address $foo_end
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
+
+ DW_LNE_set_address $bar_start
+ line [gdb_get_line_number "bar prologue"]
+ DW_LNS_copy
+ DW_LNE_set_address bar_label
+ line [gdb_get_line_number "bar return"]
+ DW_LNS_copy
+ line [gdb_get_line_number "bar end"]
+ DW_LNS_copy
+ DW_LNE_set_address $bar_end
+ DW_LNS_advance_line 1
+ DW_LNS_copy
+ DW_LNE_end_sequence
}
}
diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 3d88003ccb09..9c92115fd003 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -2410,7 +2410,7 @@ namespace eval Dwarf {
define_label $_line_header_end_label
}
- proc program {statements} {
+ proc program { body } {
variable _line_header_end_label
variable _line
@@ -2502,9 +2502,7 @@ namespace eval Dwarf {
_op .sleb128 ${num}
}
- foreach statement $statements {
- uplevel 1 $statement
- }
+ uplevel $body
}
uplevel $body
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax
2022-04-07 1:51 ` [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax Simon Marchi
@ 2022-04-07 13:52 ` Tom Tromey
2022-04-07 17:10 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-07 13:52 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> By calling `uplevel $body` in the program proc (a pattern we use at many
Simon> places), we can get rid of curly braces around each line number program
Simon> directive. That seems like a nice small improvement to me.
Agreed; looks good to me.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax
2022-04-07 13:52 ` Tom Tromey
@ 2022-04-07 17:10 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 17:10 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches
On 2022-04-07 09:52, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> By calling `uplevel $body` in the program proc (a pattern we use at many
> Simon> places), we can get rid of curly braces around each line number program
> Simon> directive. That seems like a nice small improvement to me.
>
> Agreed; looks good to me.
>
> Tom
Thanks, pushed the first 2 patches.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
2022-04-07 1:51 ` [PATCH 1/6] gdb/testsuite/dwarf: remove two unused variables Simon Marchi
2022-04-07 1:51 ` [PATCH 2/6] gdb/testsuite/dwarf: simplify line number program syntax Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-18 16:28 ` Tom Tromey
2022-04-07 1:51 ` [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile Simon Marchi
` (2 subsequent siblings)
5 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
From: Simon Marchi <simon.marchi@efficios.com>
To support DWARF 5 in the DWARF assembler line tables, we currently copy
the first user-provided directory and the first user-provided files and
make them elements at indices 0 in the directory and file name tables.
That was a sufficient behavior at the time (see commit 44fda089397a
("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in
the following patches, I would need to have finer grained control on
what is generated exactly. For example, I'd like to generate a DWARF 5 line
table with just a single file and a single directory.
Get rid of this behavior, and implement what is suggested in
44fda089397a: make include_dir return the directory index that can be
used to refer to that directory entry (based on the DWARF version), and
use it afterwards.
Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced
DWARF5 binaries will change a bit, in that they will now have a single
directory and file, where they had two before. But it doesn't change
the expected GDB behavior.
Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
---
gdb/testsuite/gdb.dwarf2/dw2-lines.exp | 9 +++--
gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp | 5 +--
gdb/testsuite/lib/dwarf.exp | 33 ++++++++++---------
3 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-lines.exp b/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
index e36064460fd3..199462358c22 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-lines.exp
@@ -79,10 +79,15 @@ proc test_1 { _cv _cdw64 _lv _ldw64 {_string_form ""}} {
}
lines [list version $lv is_64 $ldw64 string_form $string_form] Llines {
- include_dir "${srcdir}/${subdir}"
- file_name "$srcfile" 1
+ set diridx [include_dir "${srcdir}/${subdir}"]
+ file_name "$srcfile" $diridx
program {
+ # If using DWARF 5, we want to refer to file 0, but the LNP
+ # state machine is still initialized with file 1. So we need
+ # to set the current file explicitly.
+ DW_LNS_set_file $diridx
+
DW_LNE_set_address bar_label
line [line_for bar_label]
DW_LNS_copy
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp b/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
index 7fd1bd781328..9ce97fc1f265 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-prologue-end.exp
@@ -48,10 +48,11 @@ Dwarf::assemble $asm_file {
}
lines {version 5} lines_label {
- include_dir "${srcdir}/${subdir}"
- file_name "$srcfile" 1
+ set diridx [include_dir "${srcdir}/${subdir}"]
+ file_name "$srcfile" $diridx
program {
+ DW_LNS_set_file $diridx
DW_LNE_set_address $main_start
line [gdb_get_line_number "main prologue"]
DW_LNS_copy
diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 9c92115fd003..55e97c33a6e1 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -2277,14 +2277,32 @@ namespace eval Dwarf {
_op .byte 1 "standard opcode 9"
_op .byte 0 "standard opcode 10"
+ # Add a directory entry to the line table header's directory table.
+ #
+ # Return the index by which this entry can be referred to.
proc include_dir {dirname} {
variable _line_include_dirs
lappend _line_include_dirs $dirname
+
+ if { $Dwarf::_line_unit_version >= 5 } {
+ return [expr [llength $_line_include_dirs] - 1]
+ } else {
+ return [llength $_line_include_dirs]
+ }
}
+ # Add a file name entry to the line table header's file names table.
+ #
+ # Return the index by which this entry can be referred to.
proc file_name {filename diridx} {
variable _line_file_names
lappend _line_file_names $filename $diridx
+
+ if { $Dwarf::_line_unit_version >= 5 } {
+ return [expr [llength $_line_file_names] - 1]
+ } else {
+ return [llength $_line_file_names]
+ }
}
proc _line_finalize_header {} {
@@ -2316,15 +2334,8 @@ namespace eval Dwarf {
}
set nr_dirs [llength $_line_include_dirs]
- # For entry 0.
- set nr_dirs [expr $nr_dirs + 1]
_op .byte $nr_dirs "directory_count"
- # Entry 0.
- set dirname [lindex $_line_include_dirs 0]
- set _line_include_dirs \
- [concat [list $dirname] $_line_include_dirs]
-
foreach dirname $_line_include_dirs {
switch $_line_string_form {
string {
@@ -2360,16 +2371,8 @@ namespace eval Dwarf {
"file_name_entry_format (form: DW_FORM_udata)"
set nr_files [expr [llength $_line_file_names] / 2]
- # For entry 0.
- set nr_files [expr $nr_files + 1]
_op .byte $nr_files "file_names_count"
- # Entry 0.
- set filename [lindex $_line_file_names 0]
- set diridx [lindex $_line_file_names 1]
- set _line_file_names \
- [concat [list $filename $diridx] $_line_file_names]
-
foreach { filename diridx } $_line_file_names {
switch $_line_string_form {
string {
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
2022-04-07 1:51 ` [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5 Simon Marchi
@ 2022-04-18 16:28 ` Tom Tromey
2022-04-18 17:32 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-18 16:28 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Simon Marchi, Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> Get rid of this behavior, and implement what is suggested in
Simon> 44fda089397a: make include_dir return the directory index that can be
Simon> used to refer to that directory entry (based on the DWARF version), and
Simon> use it afterwards.
Thanks for doing this.
Simon> + if { $Dwarf::_line_unit_version >= 5 } {
I'm not sure I care all that much but it's more normal in this code to
use 'variable' to declare the namespace-local variable and then
reference it that way, as opposed to use the Dwarf:: prefix.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
2022-04-18 16:28 ` Tom Tromey
@ 2022-04-18 17:32 ` Simon Marchi
2022-04-18 19:28 ` Tom Tromey
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 17:32 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-18 12:28, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> Get rid of this behavior, and implement what is suggested in
> Simon> 44fda089397a: make include_dir return the directory index that can be
> Simon> used to refer to that directory entry (based on the DWARF version), and
> Simon> use it afterwards.
>
> Thanks for doing this.
>
> Simon> + if { $Dwarf::_line_unit_version >= 5 } {
>
> I'm not sure I care all that much but it's more normal in this code to
> use 'variable' to declare the namespace-local variable and then
> reference it that way, as opposed to use the Dwarf:: prefix.
Just like I prefer using $::foo for globals, I prefer using $Dwarf::_foo
for those namespace variables. It just makes it more obvious that you
are not setting a local. But I agree that it clashes with existing
code, so I can certainly change it to use the variable keyword instead.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
2022-04-18 17:32 ` Simon Marchi
@ 2022-04-18 19:28 ` Tom Tromey
2022-04-18 20:58 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-18 19:28 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Tom Tromey, Simon Marchi, Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> Just like I prefer using $::foo for globals, I prefer using $Dwarf::_foo
Simon> for those namespace variables. It just makes it more obvious that you
Simon> are not setting a local. But I agree that it clashes with existing
Simon> code, so I can certainly change it to use the variable keyword instead.
I guess it doesn't really matter to me.
"$::" is a newfangled Tcl thing which is probably why I haven't used it.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5
2022-04-18 19:28 ` Tom Tromey
@ 2022-04-18 20:58 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 20:58 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-18 15:28, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> Just like I prefer using $::foo for globals, I prefer using $Dwarf::_foo
> Simon> for those namespace variables. It just makes it more obvious that you
> Simon> are not setting a local. But I agree that it clashes with existing
> Simon> code, so I can certainly change it to use the variable keyword instead.
>
> I guess it doesn't really matter to me.
> "$::" is a newfangled Tcl thing which is probably why I haven't used it.
>
> Tom
Alright. I'll push it as is then, since this syntax makes my feel better :).
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
` (2 preceding siblings ...)
2022-04-07 1:51 ` [PATCH 3/6] gdb/testsuite/dwarf: don't automatically add directory and file entry for DWARF 5 Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-07 14:01 ` Tom Tromey
2022-04-07 1:51 ` [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Simon Marchi
2022-04-07 1:51 ` [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways Simon Marchi
5 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
From: Simon Marchi <simon.marchi@efficios.com>
Make gdb_compile handle a new "macros" option, which makes it pass the
appropriate flag to make the compiler include macro information in the
debug info. This will help simplify tests using macros, reduce
redundant code, and make it easier to add support for a new compiler.
Right now it only handles clang specially (using -fdebug-macro) and
falls back to -g3 otherwise (which works for gcc). Other compilers can
be added as needed.
Change-Id: I50cd6ab1bfbb478c1005486408e214b551364c9b
---
gdb/testsuite/gdb.base/info-macros.exp | 14 +----------
gdb/testsuite/gdb.base/macscp.exp | 11 ++-------
gdb/testsuite/gdb.base/style.exp | 23 ++++---------------
gdb/testsuite/gdb.linespec/macro-relative.exp | 9 +-------
gdb/testsuite/lib/gdb.exp | 13 +++++++++++
5 files changed, 22 insertions(+), 48 deletions(-)
diff --git a/gdb/testsuite/gdb.base/info-macros.exp b/gdb/testsuite/gdb.base/info-macros.exp
index b3e1032d76f9..39c9bc696ccf 100644
--- a/gdb/testsuite/gdb.base/info-macros.exp
+++ b/gdb/testsuite/gdb.base/info-macros.exp
@@ -21,19 +21,7 @@ if [using_fission] {
return -1
}
-set options {debug}
-
-get_compiler_info
-if { [test_compiler_info gcc*] } {
- lappend options "additional_flags=-g3"
-} elseif { [test_compiler_info clang*] } {
- lappend options "additional_flags=-fdebug-macro"
-} else {
- untested "no compiler info"
- return -1
-}
-
-if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} $options] } {
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} {debug macros}] } {
return -1
}
diff --git a/gdb/testsuite/gdb.base/macscp.exp b/gdb/testsuite/gdb.base/macscp.exp
index 4c06423e6d50..be9bd5312ff2 100644
--- a/gdb/testsuite/gdb.base/macscp.exp
+++ b/gdb/testsuite/gdb.base/macscp.exp
@@ -18,19 +18,12 @@
standard_testfile macscp1.c
set objfile [standard_output_file ${testfile}.o]
-set options { debug additional_flags=-DFROM_COMMANDLINE=ARG}
-
-get_compiler_info
-if { [test_compiler_info "gcc-*"] } {
- lappend options additional_flags=-g3
-} elseif { [test_compiler_info "clang-*"] } {
- lappend options additional_flags=-fdebug-macro
-}
+set options {debug macros additional_flags=-DFROM_COMMANDLINE=ARG}
# Generate the intermediate object file. This is required by Darwin to
# have access to the .debug_macinfo section.
if {[gdb_compile "${srcdir}/${subdir}/macscp1.c" "${objfile}" \
- object $options] != ""
+ object $options] != ""
|| [gdb_compile "${objfile}" "${binfile}" executable $options] != "" } {
untested "failed to compile"
return -1
diff --git a/gdb/testsuite/gdb.base/style.exp b/gdb/testsuite/gdb.base/style.exp
index 611b8ae52ba0..6bb5e1c9ac06 100644
--- a/gdb/testsuite/gdb.base/style.exp
+++ b/gdb/testsuite/gdb.base/style.exp
@@ -20,18 +20,7 @@ load_lib gdb-python.exp
standard_testfile
# Compile the test executable.
-set test_macros 0
-set options debug
-get_compiler_info
-if { [test_compiler_info "gcc-*"] } {
- lappend options additional_flags=-g3
- set test_macros 1
-} elseif { [test_compiler_info "clang-*"] } {
- lappend options additional_flags=-fdebug-macro
- set test_macros 1
-}
-
-if {[build_executable "failed to build" $testfile $srcfile $options]} {
+if {[build_executable "failed to build" $testfile $srcfile {debug macros}]} {
return -1
}
@@ -75,7 +64,7 @@ proc clean_restart_and_disable { args } {
# CLEAN_RESTART_AND_DISABLE instead of CLEAN_RESTART, this ensures
# that the test operates as expected as styles are disabled.
proc run_style_tests { } {
- global testfile srcfile hex binfile test_macros
+ global testfile srcfile hex binfile
global currently_disabled_style decimal hex
save_vars { env(TERM) } {
@@ -181,11 +170,9 @@ proc run_style_tests { } {
gdb_test_no_output "set width 0" ""
}
- if {$test_macros} {
- set macro_line [gdb_get_line_number "\#define SOME_MACRO"]
- gdb_test "info macro SOME_MACRO" \
- "Defined at $base_file_expr:$macro_line\r\n#define SOME_MACRO 23"
- }
+ set macro_line [gdb_get_line_number "\#define SOME_MACRO"]
+ gdb_test "info macro SOME_MACRO" \
+ "Defined at $base_file_expr:$macro_line\r\n#define SOME_MACRO 23"
gdb_test_no_output "set width 0"
diff --git a/gdb/testsuite/gdb.linespec/macro-relative.exp b/gdb/testsuite/gdb.linespec/macro-relative.exp
index f827420eb3cf..609f290d8fbe 100644
--- a/gdb/testsuite/gdb.linespec/macro-relative.exp
+++ b/gdb/testsuite/gdb.linespec/macro-relative.exp
@@ -26,14 +26,7 @@ if [is_remote host] {
return 0
}
-set opts {debug additional_flags=-I.}
-
-get_compiler_info
-if [test_compiler_info gcc*] {
- lappend opts additional_flags=-g3
-} elseif [test_compiler_info clang*] {
- lappend opts additional_flags=-fdebug-macro
-}
+set opts {debug additional_flags=-I. macros}
if { [file pathtype $objdir] == "relative" } {
untested "objdir $objdir should be absolute"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 0b242b649929..8db41154e428 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4347,6 +4347,8 @@ set gdb_saved_set_unbuffered_mode_obj ""
# - nowarnings: Inhibit all compiler warnings.
# - pie: Force creation of PIE executables.
# - nopie: Prevent creation of PIE executables.
+# - macros: Add the required compiler flag to include macro information in
+# debug information
#
# And here are some of the not too obscure options understood by DejaGnu that
# influence the compilation:
@@ -4574,6 +4576,17 @@ proc gdb_compile {source dest type options} {
lappend options "$flag"
}
+ set macros [lsearch -exact $options macros]
+ if {$macros != -1} {
+ if { [test_compiler_info "clang-*"] } {
+ set flag "additional_flags=-fdebug-macro"
+ } else {
+ set flag "additional_flags=-g3"
+ }
+
+ set options [lreplace $options $macros $macros $flag]
+ }
+
if { $type == "executable" } {
if { ([istarget "*-*-mingw*"]
|| [istarget "*-*-*djgpp"]
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile
2022-04-07 1:51 ` [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile Simon Marchi
@ 2022-04-07 14:01 ` Tom Tromey
2022-04-07 17:22 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-07 14:01 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Simon Marchi, Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> From: Simon Marchi <simon.marchi@efficios.com>
Simon> Make gdb_compile handle a new "macros" option, which makes it pass the
Simon> appropriate flag to make the compiler include macro information in the
Simon> debug info. This will help simplify tests using macros, reduce
Simon> redundant code, and make it easier to add support for a new compiler.
Simon> Right now it only handles clang specially (using -fdebug-macro) and
Simon> falls back to -g3 otherwise (which works for gcc). Other compilers can
Simon> be added as needed.
I like this idea but I think the patch changes some tests a bit.
Simon> -set options {debug}
Simon> -
Simon> -get_compiler_info
Simon> -if { [test_compiler_info gcc*] } {
Simon> - lappend options "additional_flags=-g3"
Simon> -} elseif { [test_compiler_info clang*] } {
Simon> - lappend options "additional_flags=-fdebug-macro"
Simon> -} else {
Simon> - untested "no compiler info"
Simon> - return -1
Simon> -}
Simon> -
Simon> -if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} $options] } {
Simon> +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} {debug macros}] } {
Simon> return -1
This one used to be untested for non-{gcc,clang} compilers, but now I
think the test will just fail.
There are some other cases like this as well.
Maybe this was intentional? I suppose if there's a compiler that
doesn't support this, we can go back and re-added the untested / "if"s.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile
2022-04-07 14:01 ` Tom Tromey
@ 2022-04-07 17:22 ` Simon Marchi
2022-04-07 18:31 ` Tom Tromey
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 17:22 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-07 10:01, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> From: Simon Marchi <simon.marchi@efficios.com>
> Simon> Make gdb_compile handle a new "macros" option, which makes it pass the
> Simon> appropriate flag to make the compiler include macro information in the
> Simon> debug info. This will help simplify tests using macros, reduce
> Simon> redundant code, and make it easier to add support for a new compiler.
>
> Simon> Right now it only handles clang specially (using -fdebug-macro) and
> Simon> falls back to -g3 otherwise (which works for gcc). Other compilers can
> Simon> be added as needed.
>
> I like this idea but I think the patch changes some tests a bit.
>
> Simon> -set options {debug}
> Simon> -
> Simon> -get_compiler_info
> Simon> -if { [test_compiler_info gcc*] } {
> Simon> - lappend options "additional_flags=-g3"
> Simon> -} elseif { [test_compiler_info clang*] } {
> Simon> - lappend options "additional_flags=-fdebug-macro"
> Simon> -} else {
> Simon> - untested "no compiler info"
> Simon> - return -1
> Simon> -}
> Simon> -
> Simon> -if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} $options] } {
> Simon> +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} {debug macros}] } {
> Simon> return -1
>
> This one used to be untested for non-{gcc,clang} compilers, but now I
> think the test will just fail.
>
> There are some other cases like this as well.
>
> Maybe this was intentional? I suppose if there's a compiler that
> doesn't support this, we can go back and re-added the untested / "if"s.
You're right. style.exp also changes in this way. macscp.exp, on the
other hand, simply didn't add any flags if the compiler isn't gcc nor
clang. So, they all had a slightly different behavior.
We could add a proc to do:
if { [skip_macro_tests] } {
...
}
... and in skip_macro_tests we could have an appropriate check to see if
the target compiler supports generating macro debug info. But I don't
have a compiler on hand that doesn't support macro debug info
generation, so it's not easy to write it. I think we can add it if we
face a concrete situation where someone wants to run the testsuite
against such a compiler.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile
2022-04-07 17:22 ` Simon Marchi
@ 2022-04-07 18:31 ` Tom Tromey
2022-04-07 18:41 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-07 18:31 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Tom Tromey, Simon Marchi, Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> But I don't
Simon> have a compiler on hand that doesn't support macro debug info
Simon> generation, so it's not easy to write it. I think we can add it if we
Simon> face a concrete situation where someone wants to run the testsuite
Simon> against such a compiler.
Yeah, seems alright to me. Unless someone already has such a compiler
and is listening.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile
2022-04-07 18:31 ` Tom Tromey
@ 2022-04-07 18:41 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 18:41 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-07 14:31, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> But I don't
> Simon> have a compiler on hand that doesn't support macro debug info
> Simon> generation, so it's not easy to write it. I think we can add it if we
> Simon> face a concrete situation where someone wants to run the testsuite
> Simon> against such a compiler.
>
> Yeah, seems alright to me. Unless someone already has such a compiler
> and is listening.
>
> Tom
Ok, thanks. I will push the patch, and I promise to work with said
person to implement this if needed :).
Meanwhile, I tested with icc (the Intel compiler), and it does
understand -g3 to enable macro debug info, just like gcc. So the way I
wrote it with -g3 as a fallback should make us support icc too.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
` (3 preceding siblings ...)
2022-04-07 1:51 ` [PATCH 4/6] gdb/testsuite: add "macros" option to gdb_compile Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-07 6:09 ` Eli Zaretskii
` (2 more replies)
2022-04-07 1:51 ` [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways Simon Marchi
5 siblings, 3 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches
Printing macros defined in the main source file doesn't work reliably using
various toolchains, especially when DWARF 5 is used. For example, using either
of these binaries:
$ gcc --version
gcc (GCC) 11.2.0
$ ld --version
GNU ld (GNU Binutils) 2.38
$ gcc test.c -g3 -gdwarf-5
$ clang --version
clang version 13.0.1
$ clang test.c -gdwarf-5 -fdebug-macro
I get:
$ ./gdb -nx -q --data-directory=data-directory a.out
(gdb) start
Temporary breakpoint 1 at 0x111d: file test.c, line 6.
Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out
Temporary breakpoint 1, main () at test.c:6
6 return ZERO;
(gdb) p ZERO
No symbol "ZERO" in current context.
When starting to investigate this (taking the gcc-compiled binary as an
example), we see that GDB fails to look up the appropriate macro scope
when evaluating the expression. While stopped in
macro_lookup_inclusion:
(top-gdb) p name
$1 = 0x62100011a980 "test.c"
(top-gdb) p source.filename
$2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c"
`source` is the macro_source_file that we would expect GDB to find. But
it doesn't find it because the filename it is looking for isn't exactly
like the filename as written in the macro_source_file object.
The `name` parameter comes from the symtab::filename field of the symtab
we are stopped at. The symtab's filename comes from the compilation
unit's DW_AT_name, passed to the buildsym_compunit's constructor:
https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630
The name is used as is to create the main subfile of the compunit, which
eventually becomes a symtab. In this case it is just the filename,
"test.c".
The name of the macro_source_file comes from the line number program
header's file table, from the call to the line_header::file_file_name
method:
https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65
line_header::file_file_name prepends the directory path the file is
relative to, if the file name is not absolute. In this case, the file
name is "test.c", appended to the directory
"/home/simark/build/binutils-gdb-one-target/gdb".
Because the symtab's name is not created the same way as the
macro_source_file's name is created, we get this mismatch.
This patch fixes things locally in a rather naive way by making
buildsym_compunit format the main subfile's name the same way as the
DWARF reader formats the main name, that is by prepending the directory
part. Since this changes some symtab names, there is some user-visible
changes when those names are output, as can be seen from the few tests I
needed to update. The difference is that some symtab names that
previously didn't include a directory portion will now include one.
Finally, change the comment above the line_header::file_file_name
declaration. The part about it returning a name relative the
compilation directory is just not true, it thought it was very
misleading. There isn't much we can guarantee about how the returned
file name will look like, because it depends on what the compiler
decided to put in the file and directory tables.
Change-Id: I0372906dafc01d6b3774b2ab72f9d28d7069b6cc
---
gdb/buildsym.c | 15 +++++++++++++++
| 5 +----
gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp | 2 +-
gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl | 2 +-
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 4718b201f036..c1c588a869dc 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -71,6 +71,21 @@ buildsym_compunit::buildsym_compunit (struct objfile *objfile_,
non-primary symtabs. It is also needed by get_macro_table. */
m_compunit_symtab = allocate_compunit_symtab (m_objfile, name);
+ std::string name_copy;
+
+ /* In order not to lose the line information directory,
+ we concatenate it to the filename when it makes sense.
+ Note that the Dwarf3 standard says (speaking of filenames in line
+ information): ``The directory index is ignored for file names
+ that represent full path names''. Thus ignoring dirname in the
+ `else' branch below isn't an issue. */
+
+ if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
+ {
+ name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
+ name = name_copy.c_str ();
+ }
+
/* Build the subfile for NAME (the main source file) so that we can record
a pointer to it for later.
IMPORTANT: Do not allocate a struct symtab for NAME here.
--git a/gdb/dwarf2/line-header.h b/gdb/dwarf2/line-header.h
index 8fb44be56b2e..845fbebfa8d3 100644
--- a/gdb/dwarf2/line-header.h
+++ b/gdb/dwarf2/line-header.h
@@ -162,10 +162,7 @@ struct line_header
header. These point into dwarf2_per_objfile->line_buffer. */
const gdb_byte *statement_program_start {}, *statement_program_end {};
- /* Return file name relative to the compilation directory of file
- number I in this object's file name table. The result is
- allocated using xmalloc; the caller is responsible for freeing
- it. */
+ /* Return file name of file number FILE in this object's file name table. */
gdb::unique_xmalloc_ptr<char> file_file_name (int file) const;
private:
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp b/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
index 2257dd228191..6ea68e1f997f 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
@@ -45,4 +45,4 @@ gdb_breakpoint "*outer_before"
# FAIL was:
# No line number information available for address 0x4 <outer_inner>
-gdb_test "info line inner" {Line 2 of "inner\.c" starts at address .*}
+gdb_test "info line inner" {Line 2 of "/tmp/inner\.c" starts at address .*}
diff --git a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
index fe92c530888d..d2a74c5031b1 100644
--- a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
+++ b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
@@ -126,4 +126,4 @@ if { [prepare_for_testing "failed to prepare" ${testfile} \
gdb_reinitialize_dir /tmp
# Using an absolute path is important to see the bug.
-gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file $srcfile, line .*"
+gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file /tmp/$srcfile, line .*"
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 1:51 ` [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Simon Marchi
@ 2022-04-07 6:09 ` Eli Zaretskii
2022-04-07 16:44 ` Simon Marchi
2022-04-07 15:19 ` Hannes Domani
2022-04-18 16:36 ` Tom Tromey
2 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2022-04-07 6:09 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> Date: Wed, 6 Apr 2022 21:51:58 -0400
> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>
> + if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
> + {
> + name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
Is it really the best idea to concatenate the directory and the file
this way? What is 'name' includes "./" or "../" components? what if
m_comp_dir ends in a slash or a backslash (for example, if it's just
"/")? etc. etc.
Shouldn't we use a more sophisticated API here that has some knowledge
about the semantics of file names?
Thanks.
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 6:09 ` Eli Zaretskii
@ 2022-04-07 16:44 ` Simon Marchi
2022-04-07 17:04 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 16:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 2022-04-07 02:09, Eli Zaretskii wrote:
>> Date: Wed, 6 Apr 2022 21:51:58 -0400
>> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
>>
>> + if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
>> + {
>> + name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
>
> Is it really the best idea to concatenate the directory and the file
> this way? What is 'name' includes "./" or "../" components? what if
> m_comp_dir ends in a slash or a backslash (for example, if it's just
> "/")? etc. etc.
It might not look pretty, but it should still yield a valid path.
>
> Shouldn't we use a more sophisticated API here that has some knowledge
> about the semantics of file names?
>
> Thanks.
The concatenation mimics what is done here, in dwarf2_start_subfile:
https://gitlab.com/gnutools/binutils-gdb/-/blob/591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28/gdb/dwarf2/read.c#L21658=
and here in line_header::file_file_name:
https://gitlab.com/gnutools/binutils-gdb/-/blob/591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28/gdb/dwarf2/line-header.c#L76=
Given that our symtab / macro_source_file lookup system is (for the
moment) based on looking up paths, the path for a given source file must
be built exactly the same way at the different points for things to
work. It's not ideal, but that's the way it works right now. I am open
to doing more changes later, like doing some path normalization, but I
feel it's out of scope for this patch. This patch brings one area of
GDB "on par" with other areas.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 16:44 ` Simon Marchi
@ 2022-04-07 17:04 ` Eli Zaretskii
2022-04-07 17:26 ` Simon Marchi
2022-04-18 16:35 ` Tom Tromey
0 siblings, 2 replies; 44+ messages in thread
From: Eli Zaretskii @ 2022-04-07 17:04 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> Date: Thu, 7 Apr 2022 12:44:28 -0400
> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> >> + if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
> >> + {
> >> + name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
> >
> > Is it really the best idea to concatenate the directory and the file
> > this way? What is 'name' includes "./" or "../" components? what if
> > m_comp_dir ends in a slash or a backslash (for example, if it's just
> > "/")? etc. etc.
>
> It might not look pretty, but it should still yield a valid path.
Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
different things.
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 17:04 ` Eli Zaretskii
@ 2022-04-07 17:26 ` Simon Marchi
2022-04-07 19:15 ` Eli Zaretskii
2022-04-18 16:35 ` Tom Tromey
1 sibling, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 17:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 2022-04-07 13:04, Eli Zaretskii wrote:
>> Date: Thu, 7 Apr 2022 12:44:28 -0400
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>>>> + if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
>>>> + {
>>>> + name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
>>>
>>> Is it really the best idea to concatenate the directory and the file
>>> this way? What is 'name' includes "./" or "../" components? what if
>>> m_comp_dir ends in a slash or a backslash (for example, if it's just
>>> "/")? etc. etc.
>>
>> It might not look pretty, but it should still yield a valid path.
>
> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
> different things.
Can you expand?
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 17:26 ` Simon Marchi
@ 2022-04-07 19:15 ` Eli Zaretskii
2022-04-07 19:45 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2022-04-07 19:15 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> Date: Thu, 7 Apr 2022 13:26:06 -0400
> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> >>> Is it really the best idea to concatenate the directory and the file
> >>> this way? What is 'name' includes "./" or "../" components? what if
> >>> m_comp_dir ends in a slash or a backslash (for example, if it's just
> >>> "/")? etc. etc.
> >>
> >> It might not look pretty, but it should still yield a valid path.
> >
> > Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
> > different things.
>
> Can you expand?
You mean, why is it different? Because file names which start with 2
slashes are interpreted as a UNC, where "foo" is the name of a host
and "bar" is a share on that host. See
https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 19:15 ` Eli Zaretskii
@ 2022-04-07 19:45 ` Simon Marchi
2022-04-08 4:07 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 19:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 2022-04-07 15:15, Eli Zaretskii wrote:
>> Date: Thu, 7 Apr 2022 13:26:06 -0400
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>>>>> Is it really the best idea to concatenate the directory and the file
>>>>> this way? What is 'name' includes "./" or "../" components? what if
>>>>> m_comp_dir ends in a slash or a backslash (for example, if it's just
>>>>> "/")? etc. etc.
>>>>
>>>> It might not look pretty, but it should still yield a valid path.
>>>
>>> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
>>> different things.
>>
>> Can you expand?
>
> You mean, why is it different? Because file names which start with 2
> slashes are interpreted as a UNC, where "foo" is the name of a host
> and "bar" is a share on that host. See
>
> https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention
Ok, but those use back slashes, right, not front slashes? I'm so
confused about paths in GDB on Windows, with them sometimes being
DOS-like and sometimes Unix-like.
Anyway, with my patch, the only way for you to end up with //foo/bar
would be to have "/" as the directory and "/foo/bar" as the file. But
if the file is "/foo/bar", it will be considered absolute (by
IS_ABSOLUTE_PATH), so we won't prepend the "/".
Or, it can happen if the directory is "//foo" and file is "bar", but
then the "//" comes from elsewhere.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 19:45 ` Simon Marchi
@ 2022-04-08 4:07 ` Eli Zaretskii
2022-04-08 13:54 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Eli Zaretskii @ 2022-04-08 4:07 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> Date: Thu, 7 Apr 2022 15:45:36 -0400
> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> > https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention
>
> Ok, but those use back slashes, right, not front slashes?
Windows treats both the same, so 2 forward slashes mean the same and
are interpreted the same.
> Anyway, with my patch, the only way for you to end up with //foo/bar
> would be to have "/" as the directory and "/foo/bar" as the file.
Your code inserts another slash, so if the directory is "/" and the
file is "foo/bar", it will always yield //foo/bar, AFAICT.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-08 4:07 ` Eli Zaretskii
@ 2022-04-08 13:54 ` Simon Marchi
2022-04-09 6:59 ` Eli Zaretskii
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-08 13:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 2022-04-08 00:07, Eli Zaretskii wrote:
>> Date: Thu, 7 Apr 2022 15:45:36 -0400
>> Cc: gdb-patches@sourceware.org
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>>
>>> https://en.wikipedia.org/wiki/Path_(computing)#Universal_Naming_Convention
>>
>> Ok, but those use back slashes, right, not front slashes?
>
> Windows treats both the same, so 2 forward slashes mean the same and
> are interpreted the same.
>
>> Anyway, with my patch, the only way for you to end up with //foo/bar
>> would be to have "/" as the directory and "/foo/bar" as the file.
>
> Your code inserts another slash, so if the directory is "/" and the
> file is "foo/bar", it will always yield //foo/bar, AFAICT.
Ah I see, ok.
Having a smarter function that avoids duplicate slashes would avoid
that, and should not be too complicated to write (unless maybe if we
need to handle mixed unix/dos paths). Or, do you know if we already
have something like that in our utils or libiberty?
FYI, I am also testing an alternative fix that only touches the DWARF
reader, instead of buildsym_compunit. It makes all parts of the DWARF
reader always use full absolute paths to create symtabs and
macro_source_files. That is:
1. If the file entry name is already absolute, use that.
2. Otherwise, if the directory entry pointed to by the file entry is
absolute, then use `dir + file`.
3. Otherwise, use `DW_AT_comp_dir + dir + file`.
This way, if the compiler writes something like:
DW_AT_name cwd/test.c
DW_AT_comp_dir /tmp
directory[0] /tmp
directory[1] cwd
file_name[0] cwd/test.c (dir 0)
file_name[1] test.c (dir 1)
Then GDB will realize that this is all the same file. If we add a layer
that removes the unnecessary `.` and `..` from the paths, then it can
provide additional robustness against compiler normalizing paths
inconsistently (although I haven't seen a need for this in practice, in
my tests).
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-08 13:54 ` Simon Marchi
@ 2022-04-09 6:59 ` Eli Zaretskii
0 siblings, 0 replies; 44+ messages in thread
From: Eli Zaretskii @ 2022-04-09 6:59 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> Date: Fri, 8 Apr 2022 09:54:44 -0400
> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> > Your code inserts another slash, so if the directory is "/" and the
> > file is "foo/bar", it will always yield //foo/bar, AFAICT.
>
> Ah I see, ok.
>
> Having a smarter function that avoids duplicate slashes would avoid
> that, and should not be too complicated to write (unless maybe if we
> need to handle mixed unix/dos paths). Or, do you know if we already
> have something like that in our utils or libiberty?
No, I'm not aware of such an existing function. But I don't pretend
I'm familiar with all the functions in that area to which we have
access, either in libiberty or in gdbsupport/gdb directories.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 17:04 ` Eli Zaretskii
2022-04-07 17:26 ` Simon Marchi
@ 2022-04-18 16:35 ` Tom Tromey
2022-04-18 17:36 ` Simon Marchi
1 sibling, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-18 16:35 UTC (permalink / raw)
To: Eli Zaretskii via Gdb-patches
>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>> It might not look pretty, but it should still yield a valid path.
Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
Eli> different things.
Technically, in POSIX, a leading "//" may have an implementation-defined
meaning. Or at least this was true "back in the day", I haven't exactly
kept up. I'm not aware of any implementations that do anything special
here, but I think in the distant past there was one.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 16:35 ` Tom Tromey
@ 2022-04-18 17:36 ` Simon Marchi
2022-04-18 17:59 ` Pedro Alves
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 17:36 UTC (permalink / raw)
To: Tom Tromey, Eli Zaretskii via Gdb-patches
On 2022-04-18 12:35, Tom Tromey wrote:
>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>>> It might not look pretty, but it should still yield a valid path.
>
> Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
> Eli> different things.
>
> Technically, in POSIX, a leading "//" may have an implementation-defined
> meaning. Or at least this was true "back in the day", I haven't exactly
> kept up. I'm not aware of any implementations that do anything special
> here, but I think in the distant past there was one.
>
> Tom
There's one mentionned here:
https://gitlab.com/gnutools/binutils-gdb/-/blob/dc6c21dabfbd242616b9e6266b459eded2d0762b/gdb/cli/cli-cmds.c#L606=
/* We are dealing with leading repetitions of "/..", for
example "/../..", which is the Mach super-root. */
p += 3;
I have no idea what "Mach super-root", and Googling doesn't help. I
started to get in the rabbit hole of factoring out this code that
removes . and .. from paths, but gave up for now. But I was
considering getting rid of this behavior in factor of the behavior
where /../.. simplifies to /. I tested on macOS, that's how it works
today. Perhaps someone on Hurd can tell how it works there?
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 17:36 ` Simon Marchi
@ 2022-04-18 17:59 ` Pedro Alves
2022-04-18 18:19 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Pedro Alves @ 2022-04-18 17:59 UTC (permalink / raw)
To: Simon Marchi, Tom Tromey, Eli Zaretskii via Gdb-patches
On 2022-04-18 18:36, Simon Marchi via Gdb-patches wrote:
>
>
> On 2022-04-18 12:35, Tom Tromey wrote:
>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>>
>>>> It might not look pretty, but it should still yield a valid path.
>>
>> Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
>> Eli> different things.
>>
>> Technically, in POSIX, a leading "//" may have an implementation-defined
>> meaning. Or at least this was true "back in the day", I haven't exactly
>> kept up. I'm not aware of any implementations that do anything special
>> here, but I think in the distant past there was one.
>>
>> Tom
>
> There's one mentionned here:
>
> https://gitlab.com/gnutools/binutils-gdb/-/blob/dc6c21dabfbd242616b9e6266b459eded2d0762b/gdb/cli/cli-cmds.c#L606=
>
> /* We are dealing with leading repetitions of "/..", for
> example "/../..", which is the Mach super-root. */
> p += 3;
>
> I have no idea what "Mach super-root", and Googling doesn't help. I
> started to get in the rabbit hole of factoring out this code that
> removes . and .. from paths, but gave up for now. But I was
> considering getting rid of this behavior in factor of the behavior
> where /../.. simplifies to /. I tested on macOS, that's how it works
> today. Perhaps someone on Hurd can tell how it works there?
The autoconf manual, mentions, here:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/File-System-Conventions.html
"Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants
treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise
reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it."
Mach here probably refers to the Mach microkernel used in the Gnu Hurd.
I have no idea whether any of this is still relevant.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 17:59 ` Pedro Alves
@ 2022-04-18 18:19 ` Simon Marchi
2022-04-18 18:25 ` Pedro Alves
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 18:19 UTC (permalink / raw)
To: Pedro Alves, Tom Tromey, Eli Zaretskii via Gdb-patches
On 2022-04-18 13:59, Pedro Alves wrote:
> On 2022-04-18 18:36, Simon Marchi via Gdb-patches wrote:
>>
>>
>> On 2022-04-18 12:35, Tom Tromey wrote:
>>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>>>
>>>>> It might not look pretty, but it should still yield a valid path.
>>>
>>> Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
>>> Eli> different things.
>>>
>>> Technically, in POSIX, a leading "//" may have an implementation-defined
>>> meaning. Or at least this was true "back in the day", I haven't exactly
>>> kept up. I'm not aware of any implementations that do anything special
>>> here, but I think in the distant past there was one.
>>>
>>> Tom
>>
>> There's one mentionned here:
>>
>> https://gitlab.com/gnutools/binutils-gdb/-/blob/dc6c21dabfbd242616b9e6266b459eded2d0762b/gdb/cli/cli-cmds.c#L606=
>>
>> /* We are dealing with leading repetitions of "/..", for
>> example "/../..", which is the Mach super-root. */
>> p += 3;
>>
>> I have no idea what "Mach super-root", and Googling doesn't help. I
>> started to get in the rabbit hole of factoring out this code that
>> removes . and .. from paths, but gave up for now. But I was
>> considering getting rid of this behavior in factor of the behavior
>> where /../.. simplifies to /. I tested on macOS, that's how it works
>> today. Perhaps someone on Hurd can tell how it works there?
>
> The autoconf manual, mentions, here:
>
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/File-System-Conventions.html
>
> "Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants
> treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise
> reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it."
Ok, that's a different "super-root" syntax then. What's supported in
cd_command (my link above) talks about repeated leading "/..".
I just tried "ls //foo" on Cygwin. It gave "no such file or
directory", but it took a while to return, so I guess it's just handling
it as a UNC path, trying to look up computer "foo" on my network (as Eli
told initially).
> Mach here probably refers to the Mach microkernel used in the Gnu Hurd.
Yeah, that's why I asked. If somebody has a Hurd system handy. If Hurd
treats /../.. as /, then I would vote to get rid of that behavior in
cd_command, since there would be no known-to-us platform where it works
like that.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 18:19 ` Simon Marchi
@ 2022-04-18 18:25 ` Pedro Alves
2022-04-18 20:33 ` Samuel Thibault
0 siblings, 1 reply; 44+ messages in thread
From: Pedro Alves @ 2022-04-18 18:25 UTC (permalink / raw)
To: Simon Marchi, Tom Tromey, Eli Zaretskii via Gdb-patches, Samuel Thibault
[Adding Samuel.]
Samuel, please see Hurd question below.
On 2022-04-18 19:19, Simon Marchi wrote:
>
>
> On 2022-04-18 13:59, Pedro Alves wrote:
>> On 2022-04-18 18:36, Simon Marchi via Gdb-patches wrote:
>>>
>>>
>>> On 2022-04-18 12:35, Tom Tromey wrote:
>>>>>>>>> "Eli" == Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org> writes:
>>>>
>>>>>> It might not look pretty, but it should still yield a valid path.
>>>>
>>>> Eli> Well, at least on MS-Windows, "/foo/bar" and "//foo/bar" are very
>>>> Eli> different things.
>>>>
>>>> Technically, in POSIX, a leading "//" may have an implementation-defined
>>>> meaning. Or at least this was true "back in the day", I haven't exactly
>>>> kept up. I'm not aware of any implementations that do anything special
>>>> here, but I think in the distant past there was one.
>>>>
>>>> Tom
>>>
>>> There's one mentionned here:
>>>
>>> https://gitlab.com/gnutools/binutils-gdb/-/blob/dc6c21dabfbd242616b9e6266b459eded2d0762b/gdb/cli/cli-cmds.c#L606=
>>>
>>> /* We are dealing with leading repetitions of "/..", for
>>> example "/../..", which is the Mach super-root. */
>>> p += 3;
>>>
>>> I have no idea what "Mach super-root", and Googling doesn't help. I
>>> started to get in the rabbit hole of factoring out this code that
>>> removes . and .. from paths, but gave up for now. But I was
>>> considering getting rid of this behavior in factor of the behavior
>>> where /../.. simplifies to /. I tested on macOS, that's how it works
>>> today. Perhaps someone on Hurd can tell how it works there?
>>
>> The autoconf manual, mentions, here:
>>
>> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/File-System-Conventions.html
>>
>> "Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants
>> treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise
>> reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it."
>
> Ok, that's a different "super-root" syntax then. What's supported in
> cd_command (my link above) talks about repeated leading "/..".
>
> I just tried "ls //foo" on Cygwin. It gave "no such file or
> directory", but it took a while to return, so I guess it's just handling
> it as a UNC path, trying to look up computer "foo" on my network (as Eli
> told initially).
>
>> Mach here probably refers to the Mach microkernel used in the Gnu Hurd.
>
> Yeah, that's why I asked. If somebody has a Hurd system handy. If Hurd
> treats /../.. as /, then I would vote to get rid of that behavior in
> cd_command, since there would be no known-to-us platform where it works
> like that.
>
> Simon
>
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 18:25 ` Pedro Alves
@ 2022-04-18 20:33 ` Samuel Thibault
2022-04-18 20:56 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Samuel Thibault @ 2022-04-18 20:33 UTC (permalink / raw)
To: Pedro Alves; +Cc: Simon Marchi, Tom Tromey, Eli Zaretskii via Gdb-patches
Hello,
Pedro Alves, le lun. 18 avril 2022 19:25:08 +0100, a ecrit:
> Samuel, please see Hurd question below.
Thanks for the notice!
> On 2022-04-18 19:19, Simon Marchi wrote:
> > On 2022-04-18 13:59, Pedro Alves wrote:
> >> "Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants
> >> treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise
> >> reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it."
> >> Mach here probably refers to the Mach microkernel used in the Gnu Hurd.
> >
> > Yeah, that's why I asked.
I don't know about Mach super-root.
> > If somebody has a Hurd system handy. If Hurd treats /../.. as /,
Yes it does: it follows posix standards, there is no notion of
"super-root" / UNC etc., magic stuff is in /dev/ and /servers/
Samuel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 20:33 ` Samuel Thibault
@ 2022-04-18 20:56 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 20:56 UTC (permalink / raw)
To: Samuel Thibault, Pedro Alves; +Cc: Tom Tromey, Eli Zaretskii via Gdb-patches
On 2022-04-18 16:33, Samuel Thibault wrote:
> Hello,
>
> Pedro Alves, le lun. 18 avril 2022 19:25:08 +0100, a ecrit:
>> Samuel, please see Hurd question below.
>
> Thanks for the notice!
>
>> On 2022-04-18 19:19, Simon Marchi wrote:
>>> On 2022-04-18 13:59, Pedro Alves wrote:
>>>> "Posix lets implementations treat leading // specially, but requires leading /// and beyond to be equivalent to /. Most Unix variants
>>>> treat // like /. However, some treat // as a “super-root” that can provide access to files that are not otherwise
>>>> reachable from /. The super-root tradition began with Apollo Domain/OS, which died out long ago, but unfortunately Cygwin has revived it."
>
>>>> Mach here probably refers to the Mach microkernel used in the Gnu Hurd.
>>>
>>> Yeah, that's why I asked.
>
> I don't know about Mach super-root.
>
>>> If somebody has a Hurd system handy. If Hurd treats /../.. as /,
>
> Yes it does: it follows posix standards, there is no notion of
> "super-root" / UNC etc., magic stuff is in /dev/ and /servers/
Thanks Samuel.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 1:51 ` [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Simon Marchi
2022-04-07 6:09 ` Eli Zaretskii
@ 2022-04-07 15:19 ` Hannes Domani
2022-04-07 18:01 ` Simon Marchi
2022-04-18 16:36 ` Tom Tromey
2 siblings, 1 reply; 44+ messages in thread
From: Hannes Domani @ 2022-04-07 15:19 UTC (permalink / raw)
To: gdb-patches, Simon Marchi
Am Donnerstag, 7. April 2022, 03:55:39 MESZ hat Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:
> Printing macros defined in the main source file doesn't work reliably using
> various toolchains, especially when DWARF 5 is used. For example, using either
> of these binaries:
>
> $ gcc --version
> gcc (GCC) 11.2.0
> $ ld --version
> GNU ld (GNU Binutils) 2.38
> $ gcc test.c -g3 -gdwarf-5
>
> $ clang --version
> clang version 13.0.1
> $ clang test.c -gdwarf-5 -fdebug-macro
>
> I get:
>
> $ ./gdb -nx -q --data-directory=data-directory a.out
> (gdb) start
> Temporary breakpoint 1 at 0x111d: file test.c, line 6.
> Starting program: /home/simark/build/binutils-gdb-one-target/gdb/a.out
>
> Temporary breakpoint 1, main () at test.c:6
> 6 return ZERO;
> (gdb) p ZERO
> No symbol "ZERO" in current context.
>
> When starting to investigate this (taking the gcc-compiled binary as an
> example), we see that GDB fails to look up the appropriate macro scope
> when evaluating the expression. While stopped in
> macro_lookup_inclusion:
>
> (top-gdb) p name
> $1 = 0x62100011a980 "test.c"
> (top-gdb) p source.filename
> $2 = 0x62100011a9a0 "/home/simark/build/binutils-gdb-one-target/gdb/test.c"
>
> `source` is the macro_source_file that we would expect GDB to find. But
> it doesn't find it because the filename it is looking for isn't exactly
> like the filename as written in the macro_source_file object.
>
> The `name` parameter comes from the symtab::filename field of the symtab
> we are stopped at. The symtab's filename comes from the compilation
> unit's DW_AT_name, passed to the buildsym_compunit's constructor:
>
> https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630
>
> The name is used as is to create the main subfile of the compunit, which
> eventually becomes a symtab. In this case it is just the filename,
> "test.c".
>
> The name of the macro_source_file comes from the line number program
> header's file table, from the call to the line_header::file_file_name
> method:
>
> https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec580cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65
>
> line_header::file_file_name prepends the directory path the file is
> relative to, if the file name is not absolute. In this case, the file
> name is "test.c", appended to the directory
> "/home/simark/build/binutils-gdb-one-target/gdb".
>
> Because the symtab's name is not created the same way as the
> macro_source_file's name is created, we get this mismatch.
>
> This patch fixes things locally in a rather naive way by making
> buildsym_compunit format the main subfile's name the same way as the
> DWARF reader formats the main name, that is by prepending the directory
> part. Since this changes some symtab names, there is some user-visible
> changes when those names are output, as can be seen from the few tests I
> needed to update. The difference is that some symtab names that
> previously didn't include a directory portion will now include one.
>
> Finally, change the comment above the line_header::file_file_name
> declaration. The part about it returning a name relative the
> compilation directory is just not true, it thought it was very
> misleading. There isn't much we can guarantee about how the returned
> file name will look like, because it depends on what the compiler
> decided to put in the file and directory tables.
>
> Change-Id: I0372906dafc01d6b3774b2ab72f9d28d7069b6cc
> ---
> gdb/buildsym.c | 15 +++++++++++++++
> gdb/dwarf2/line-header.h | 5 +----
> gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp | 2 +-
> gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl | 2 +-
> 4 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/buildsym.c b/gdb/buildsym.c
> index 4718b201f036..c1c588a869dc 100644
> --- a/gdb/buildsym.c
> +++ b/gdb/buildsym.c
> @@ -71,6 +71,21 @@ buildsym_compunit::buildsym_compunit (struct objfile *objfile_,
> non-primary symtabs. It is also needed by get_macro_table. */
> m_compunit_symtab = allocate_compunit_symtab (m_objfile, name);
>
> + std::string name_copy;
> +
> + /* In order not to lose the line information directory,
> + we concatenate it to the filename when it makes sense.
> + Note that the Dwarf3 standard says (speaking of filenames in line
> + information): ``The directory index is ignored for file names
> + that represent full path names''. Thus ignoring dirname in the
> + `else' branch below isn't an issue. */
> +
> + if (!IS_ABSOLUTE_PATH (name) && m_comp_dir != nullptr)
> + {
> + name_copy = string_printf ("%s/%s", m_comp_dir.get (), name);
> + name = name_copy.c_str ();
> + }
> +
> /* Build the subfile for NAME (the main source file) so that we can record
> a pointer to it for later.
> IMPORTANT: Do not allocate a struct symtab for NAME here.
> diff --git a/gdb/dwarf2/line-header.h b/gdb/dwarf2/line-header.h
> index 8fb44be56b2e..845fbebfa8d3 100644
> --- a/gdb/dwarf2/line-header.h
> +++ b/gdb/dwarf2/line-header.h
> @@ -162,10 +162,7 @@ struct line_header
> header. These point into dwarf2_per_objfile->line_buffer. */
> const gdb_byte *statement_program_start {}, *statement_program_end {};
>
> - /* Return file name relative to the compilation directory of file
> - number I in this object's file name table. The result is
> - allocated using xmalloc; the caller is responsible for freeing
> - it. */
> + /* Return file name of file number FILE in this object's file name table. */
> gdb::unique_xmalloc_ptr<char> file_file_name (int file) const;
>
> private:
> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp b/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
> index 2257dd228191..6ea68e1f997f 100644
> --- a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
> +++ b/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp
> @@ -45,4 +45,4 @@ gdb_breakpoint "*outer_before"
>
> # FAIL was:
> # No line number information available for address 0x4 <outer_inner>
> -gdb_test "info line inner" {Line 2 of "inner\.c" starts at address .*}
> +gdb_test "info line inner" {Line 2 of "/tmp/inner\.c" starts at address .*}
> diff --git a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
> index fe92c530888d..d2a74c5031b1 100644
> --- a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
> +++ b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl
> @@ -126,4 +126,4 @@ if { [prepare_for_testing "failed to prepare" ${testfile} \
> gdb_reinitialize_dir /tmp
>
> # Using an absolute path is important to see the bug.
> -gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file $srcfile, line .*"
> +gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file /tmp/$srcfile, line .*"
>
> --
> 2.35.1
I came up with a different fix:
--- a/gdb/dwarf2/line-header.c
+++ b/gdb/dwarf2/line-header.c
@@ -69,7 +69,11 @@ line_header::file_file_name (int file) const
{
const file_entry *fe = file_name_at (file);
- if (!IS_ABSOLUTE_PATH (fe->name))
+ /* The directory index 0 always means the compilation directory.
+ For DWARF 4 and before because 0 means DW_AT_comp_dir, and
+ for DWARF 5 because the first entry of the directory table is
+ the compilation directory. */
+ if (!IS_ABSOLUTE_PATH (fe->name) && fe->d_index > 0)
{
const char *dir = fe->include_dir (this);
if (dir != NULL)
But there is probably a good reason why you didn't choose this variant.
Regards
Hannes
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 15:19 ` Hannes Domani
@ 2022-04-07 18:01 ` Simon Marchi
2022-04-21 10:56 ` Hannes Domani
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 18:01 UTC (permalink / raw)
To: Hannes Domani, gdb-patches
> I came up with a different fix:
>
> --- a/gdb/dwarf2/line-header.c
> +++ b/gdb/dwarf2/line-header.c
> @@ -69,7 +69,11 @@ line_header::file_file_name (int file) const
> {
> const file_entry *fe = file_name_at (file);
>
> - if (!IS_ABSOLUTE_PATH (fe->name))
> + /* The directory index 0 always means the compilation directory.
> + For DWARF 4 and before because 0 means DW_AT_comp_dir, and
> + for DWARF 5 because the first entry of the directory table is
> + the compilation directory. */
> + if (!IS_ABSOLUTE_PATH (fe->name) && fe->d_index > 0)
> {
> const char *dir = fe->include_dir (this);
> if (dir != NULL)
>
>
> But there is probably a good reason why you didn't choose this variant.
I did have something like this as my first attempts:
https://review.lttng.org/c/binutils-gdb/+/7662/15/gdb/dwarf2/line-header.c
But it does not make the test cases happy:
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print ONE
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print TWO
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print ONE
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print TWO
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print ONE
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print TWO
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print ONE
FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print TWO
Or on my current system (gcc 11 + ld 2.38):
FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print ONE
FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print TWO
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 18:01 ` Simon Marchi
@ 2022-04-21 10:56 ` Hannes Domani
2022-04-21 20:26 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Hannes Domani @ 2022-04-21 10:56 UTC (permalink / raw)
To: gdb-patches, Simon Marchi
Am Donnerstag, 7. April 2022, 20:01:33 MESZ hat Simon Marchi <simon.marchi@polymtl.ca> Folgendes geschrieben:
> > I came up with a different fix:
> >
> > --- a/gdb/dwarf2/line-header.c
> > +++ b/gdb/dwarf2/line-header.c
> > @@ -69,7 +69,11 @@ line_header::file_file_name (int file) const
> > {
> > const file_entry *fe = file_name_at (file);
> >
> > - if (!IS_ABSOLUTE_PATH (fe->name))
> > + /* The directory index 0 always means the compilation directory.
> > + For DWARF 4 and before because 0 means DW_AT_comp_dir, and
> > + for DWARF 5 because the first entry of the directory table is
> > + the compilation directory. */
> > + if (!IS_ABSOLUTE_PATH (fe->name) && fe->d_index > 0)
> > {
> > const char *dir = fe->include_dir (this);
> > if (dir != NULL)
> >
> >
> > But there is probably a good reason why you didn't choose this variant.
>
> I did have something like this as my first attempts:
>
> https://review.lttng.org/c/binutils-gdb/+/7662/15/gdb/dwarf2/line-header.c
>
> But it does not make the test cases happy:
>
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print ONE
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print TWO
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print ONE
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print TWO
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print ONE
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print TWO
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print ONE
> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print TWO
>
> Or on my current system (gcc 11 + ld 2.38):
>
> FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print ONE
> FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print TWO
I wonder if this variant could still be applied to gdb-12-branch, since
it does fix most problems, and isn't very intrusive.
Hannes
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-21 10:56 ` Hannes Domani
@ 2022-04-21 20:26 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-21 20:26 UTC (permalink / raw)
To: Hannes Domani, gdb-patches
On 2022-04-21 06:56, Hannes Domani wrote:
> Am Donnerstag, 7. April 2022, 20:01:33 MESZ hat Simon Marchi <simon.marchi@polymtl.ca> Folgendes geschrieben:
>
>>> I came up with a different fix:
>>>
>>> --- a/gdb/dwarf2/line-header.c
>>> +++ b/gdb/dwarf2/line-header.c
>>> @@ -69,7 +69,11 @@ line_header::file_file_name (int file) const
>>> {
>>> const file_entry *fe = file_name_at (file);
>>>
>>> - if (!IS_ABSOLUTE_PATH (fe->name))
>>> + /* The directory index 0 always means the compilation directory.
>>> + For DWARF 4 and before because 0 means DW_AT_comp_dir, and
>>> + for DWARF 5 because the first entry of the directory table is
>>> + the compilation directory. */
>>> + if (!IS_ABSOLUTE_PATH (fe->name) && fe->d_index > 0)
>>> {
>>> const char *dir = fe->include_dir (this);
>>> if (dir != NULL)
>>>
>>>
>>> But there is probably a good reason why you didn't choose this variant.
>>
>> I did have something like this as my first attempts:
>>
>> https://review.lttng.org/c/binutils-gdb/+/7662/15/gdb/dwarf2/line-header.c
>>
>> But it does not make the test cases happy:
>>
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print ONE
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=true: print TWO
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print ONE
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=gcc11-ld238-absolute-cwd: is_64=false: print TWO
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print ONE
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=true: print TWO
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print ONE
>> FAIL: gdb.dwarf2/macro-source-path.exp: test_name=clang14-absolute-cwd: is_64=false: print TWO
>>
>> Or on my current system (gcc 11 + ld 2.38):
>>
>> FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print ONE
>> FAIL: gdb.base/macro-source-path.exp: absolute-cwd: print TWO
>
> I wonder if this variant could still be applied to gdb-12-branch, since
> it does fix most problems, and isn't very intrusive.
>
>
> Hannes
We could. I don't think I'll work on that myself, but if somebody else would
like to submit something, I can review it.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-07 1:51 ` [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Simon Marchi
2022-04-07 6:09 ` Eli Zaretskii
2022-04-07 15:19 ` Hannes Domani
@ 2022-04-18 16:36 ` Tom Tromey
2022-04-18 20:18 ` Simon Marchi
2 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-18 16:36 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> This patch fixes things locally in a rather naive way by making
Simon> buildsym_compunit format the main subfile's name the same way as the
Simon> DWARF reader formats the main name, that is by prepending the directory
Simon> part.
This looks good to me.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit
2022-04-18 16:36 ` Tom Tromey
@ 2022-04-18 20:18 ` Simon Marchi
0 siblings, 0 replies; 44+ messages in thread
From: Simon Marchi @ 2022-04-18 20:18 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches
On 2022-04-18 12:36, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> This patch fixes things locally in a rather naive way by making
> Simon> buildsym_compunit format the main subfile's name the same way as the
> Simon> DWARF reader formats the main name, that is by prepending the directory
> Simon> part.
>
> This looks good to me.
FYI, my next version will use a different method. The "problem" with
this one is that the path to the main source file still gets expressed
in different ways in some cases. When constructing the
buildsym_compunit, the path comes from the compilation unit's
DW_AT_comp_dir + DW_AT_name. And that can give a different result than
a when built from the line table header. Things still work, but only
because of the heuristic in watch_main_source_file_lossage. But I'd
rather avoid that if possible.
Instead, I am changing the DWARF reader to always use "full paths"
everwhere.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways
2022-04-07 1:51 [PATCH 0/6] Fix printing macros Simon Marchi
` (4 preceding siblings ...)
2022-04-07 1:51 ` [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit Simon Marchi
@ 2022-04-07 1:51 ` Simon Marchi
2022-04-18 16:53 ` Tom Tromey
5 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-07 1:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
From: Simon Marchi <simon.marchi@efficios.com>
Using different ways of passing source file paths to compilers results
result in different contents of the line table file and directory
tables. Because of this, GDB sometimes failed to look up macros. The
previous patch fixed that as much as possible. This patch adds the
corresponding tests.
Add both a DWARF assembler-based test and a regular test. The DWARF
assembled-based one tests some hard-coded debug info based on what I
have seen some specific versions of gcc and clang generate. We want to
make sure that GDB keeps handling all these cases correctly, even if
it's not always clear whether they are really valid DWARF.
The regular test is compiled using the target compiler, so it may help
find bugs when testing against some other toolchain than what was used
to generate the DWARF assembler-based test.
For the DWARF assembler-based test, add to testsuite/lib/dwarf.exp the
necessary code to generate a DWARF5 .debug_macro section. The design of
the new procs is based on what was done for rnglists and loclists.
To test against a specific compiler one can use this command, for
example:
$ make check TESTS="gdb.base/macro-source-path.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang --target_board unix/gdb:debug_flags=-gdwarf-5"
Change-Id: Iab8da498e57d10cc2a3d09ea136685d9278cfcf6
---
gdb/testsuite/gdb.base/macro-source-path.c | 22 ++
gdb/testsuite/gdb.base/macro-source-path.exp | 79 +++++
gdb/testsuite/gdb.dwarf2/macro-source-path.c | 20 ++
.../gdb.dwarf2/macro-source-path.exp | 299 ++++++++++++++++++
gdb/testsuite/lib/dwarf.exp | 92 ++++++
5 files changed, 512 insertions(+)
create mode 100644 gdb/testsuite/gdb.base/macro-source-path.c
create mode 100644 gdb/testsuite/gdb.base/macro-source-path.exp
create mode 100644 gdb/testsuite/gdb.dwarf2/macro-source-path.c
create mode 100644 gdb/testsuite/gdb.dwarf2/macro-source-path.exp
diff --git a/gdb/testsuite/gdb.base/macro-source-path.c b/gdb/testsuite/gdb.base/macro-source-path.c
new file mode 100644
index 000000000000..f4ede117a2a0
--- /dev/null
+++ b/gdb/testsuite/gdb.base/macro-source-path.c
@@ -0,0 +1,22 @@
+/* Copyright 2022 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/>. */
+
+#define TWO 2
+
+int
+main (void)
+{
+ return ONE + TWO;
+}
diff --git a/gdb/testsuite/gdb.base/macro-source-path.exp b/gdb/testsuite/gdb.base/macro-source-path.exp
new file mode 100644
index 000000000000..710f5a61d941
--- /dev/null
+++ b/gdb/testsuite/gdb.base/macro-source-path.exp
@@ -0,0 +1,79 @@
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2022 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/>.
+
+# Compile a source file using different ways of passing the path to the
+# compiler. Then, verify that we can print a macro defined in that file.
+
+standard_testfile
+
+# Copy the source file at these locations in the output directory ($out):
+#
+# $out/cwd/macro-source-path.c
+# $out/other/macro-source-path.c
+#
+# Set the current working directory to $out/cwd, so that we can test compiling
+# using relative paths.
+
+set out_dir [standard_output_file ""]
+file mkdir $out_dir/cwd
+file mkdir $out_dir/other
+file copy -force $srcdir/$subdir/$srcfile $out_dir/cwd
+file copy -force $srcdir/$subdir/$srcfile $out_dir/other
+cd $out_dir/cwd
+
+# Run one test.
+#
+# SRC is the path to the source file, to be passed to the compiler as-is.
+# NAME is the name of the test.
+
+proc test { src name } {
+ with_test_prefix $name {
+ set binfile $::out_dir/$name
+
+ if { [gdb_compile $src $binfile executable {debug macros additional_flags=-DONE=1}] != "" } {
+ fail "could not compile"
+ return
+ }
+
+ clean_restart $binfile
+
+ if { ![runto_main] } {
+ return
+ }
+
+ # Print the macro that is defined on the command-line.
+ if { [test_compiler_info "clang-*"] } {
+ # This is really a clang bug, it puts the macros defined on the command
+ # line after the main source file, in the macro table.
+ setup_kfail "gdb/29034" "*-*-*"
+ }
+ gdb_test "print ONE" " = 1"
+
+ # Print the macro that is defined in the main file.
+ gdb_test "print TWO" " = 2"
+ }
+}
+
+# When adding a test here, please consider adding an equivalent case to the test
+# of the same name in gdb.dwarf2.
+
+test $testfile.c filename
+test ./$testfile.c dot-filename
+test ../cwd/$testfile.c dot-dot-filename
+test [file normalize $testfile.c] absolute-cwd
+test ../other/$testfile.c dot-dot-other
+test [file normalize ../other/$testfile.c] absolute-other
diff --git a/gdb/testsuite/gdb.dwarf2/macro-source-path.c b/gdb/testsuite/gdb.dwarf2/macro-source-path.c
new file mode 100644
index 000000000000..749bcc1580ee
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/macro-source-path.c
@@ -0,0 +1,20 @@
+/* Copyright 2022 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/>. */
+
+int
+main (void)
+{
+ asm ("main_label: .globl main_label");
+}
diff --git a/gdb/testsuite/gdb.dwarf2/macro-source-path.exp b/gdb/testsuite/gdb.dwarf2/macro-source-path.exp
new file mode 100644
index 000000000000..0b2b6e0277de
--- /dev/null
+++ b/gdb/testsuite/gdb.dwarf2/macro-source-path.exp
@@ -0,0 +1,299 @@
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2022 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/>.
+
+# Generate binaries imitating different ways source file paths can be passed to
+# compilers. Test printing macros from those binaries.
+
+load_lib dwarf.exp
+
+if {![dwarf2_support]} {
+ return 0
+}
+
+standard_testfile .c
+
+lassign [function_range main $srcdir/$subdir/$srcfile] \
+ main_start main_len
+
+# Run one test.
+#
+# - TEST_NAME is the name of the test, used to differentiate the binaries.
+# - LINES_VERSION is the version of the version of the .debug_line section to
+# generate.
+# - DW_AT_NAME is the string to put in the compilation unit's DW_AT_name
+# attribute.
+# - MAIN_FILE_IDX is the file index the .debug_line and .debug_macro sections
+# will use to refer to the main file.
+# - DIRECTORIES is a list of directories to put in the .debug_line section
+# header
+# - FILE_NAMES is a list of {name, directory index} pairs describing the files
+# names to put in the .debug_line section header.
+
+proc do_test { test_name lines_version DW_AT_name main_file_idx directories
+ file_names } {
+ with_test_prefix "test_name=$test_name" {
+ foreach_with_prefix is_64 {true false} {
+ # So we can access them in Dwarf::assemble...
+ set ::lines_version $lines_version
+ set ::DW_AT_name $DW_AT_name
+ set ::main_file_idx $main_file_idx
+ set ::directories $directories
+ set ::file_names $file_names
+ set ::is_64 $is_64
+ set 32_or_64 [expr $is_64 ? 64 : 32]
+
+ set asm_file [standard_output_file ${::testfile}-${test_name}-${32_or_64}.S]
+ Dwarf::assemble $asm_file {
+ declare_labels Llines cu_macros
+
+ # DW_AT_comp_dir is always the current working directory
+ # from which the compiler was invoked. We pretend the compiler was
+ # always launched from /tmp/cwd.
+ set comp_dir "/tmp/cwd"
+
+ cu {} {
+ DW_TAG_compile_unit {
+ {DW_AT_producer "My C Compiler"}
+ {DW_AT_language @DW_LANG_C11}
+ {DW_AT_name $::DW_AT_name}
+ {DW_AT_comp_dir $comp_dir}
+ {DW_AT_stmt_list $Llines DW_FORM_sec_offset}
+ {DW_AT_macros $cu_macros DW_FORM_sec_offset}
+ } {
+ declare_labels int_type
+
+ int_type: DW_TAG_base_type {
+ {DW_AT_byte_size 4 DW_FORM_sdata}
+ {DW_AT_encoding @DW_ATE_signed}
+ {DW_AT_name int}
+ }
+
+ DW_TAG_subprogram {
+ {MACRO_AT_func {main}}
+ {type :$int_type}
+ }
+ }
+ }
+
+ # Define the .debug_line section.
+ lines [list version $::lines_version] "Llines" {
+ foreach directory $::directories {
+ include_dir $directory
+ }
+
+ foreach file_name $::file_names {
+ lassign $file_name name dir_index
+ file_name $name $dir_index
+ }
+
+ # A line number program just good enough so that GDB can
+ # figure out we are stopped in main.
+ program {
+ DW_LNS_set_file $::main_file_idx
+ DW_LNE_set_address $::main_start
+ line 10
+ DW_LNS_copy
+
+ DW_LNE_set_address "$::main_start + $::main_len"
+ DW_LNE_end_sequence
+ }
+ }
+
+ # Define the .debug_macro section.
+ macro {
+ cu_macros: unit {
+ "debug-line-offset-label" $Llines
+ "is-64" $::is_64
+ } {
+ # A macro defined outside the main file, as if it was defined
+ # on the command line with -D.
+ define 0 "ONE 1"
+ start_file 0 $::main_file_idx
+ # A macro defined at line 1 of the main file.
+ define 1 "TWO 2"
+ end_file
+ }
+ }
+ }
+
+ if { [prepare_for_testing "failed to prepare" ${::testfile}-${test_name}-${32_or_64} \
+ [list $::srcfile $asm_file] {nodebug}] } {
+ return
+ }
+
+ if ![runto_main] {
+ return
+ }
+
+ gdb_test "print ONE" " = 1"
+ gdb_test "print TWO" " = 2"
+ }
+ }
+}
+
+# When adding a test here, please consider adding an equivalent case to the test
+# of the same name in gdb.base.
+
+# Based on `gcc -gdwarf-5 -g3 <file>`, gcc 11 paired with as from binutils 2.38.
+
+## test.c
+do_test gcc11-ld238-filename 5 "test.c" 1 {
+ "/tmp/cwd"
+} {
+ {"test.c" 0}
+ {"test.c" 0}
+}
+
+## ./test.c
+do_test gcc11-ld238-dot-filename 5 "./test.c" 1 {
+ "/tmp/cwd"
+ "."
+} {
+ {"test.c" 1}
+ {"test.c" 1}
+}
+
+## ../cwd/test.c
+do_test gcc11-ld238-dot-dot-cwd 5 "../cwd/test.c" 1 {
+ "/tmp/cwd"
+ "../cwd"
+} {
+ {"test.c" 1}
+ {"test.c" 1}
+}
+
+## /tmp/cwd/test.c
+do_test gcc11-ld238-absolute-cwd 5 "/tmp/cwd/test.c" 1 {
+ "/tmp/cwd"
+ "/tmp/cwd"
+} {
+ {"test.c" 1}
+ {"test.c" 0}
+}
+
+## ../other/test.c
+do_test gcc11-ld238-dot-dot-other 5 "../other/test.c" 1 {
+ "/tmp/cwd"
+ "../other"
+} {
+ {"test.c" 1}
+ {"test.c" 1}
+}
+
+## /tmp/other/test.c
+do_test gcc11-ld238-absolute-other 5 "/tmp/other/test.c" 1 {
+ "/tmp/cwd"
+ "/tmp/other"
+} {
+ {"test.c" 1}
+ {"test.c" 1}
+}
+
+# Based on `clang-14 -gdwarf-5 -fdebug-macro -g3 <file>` (using its
+# built-in assembler)
+
+## test.c
+do_test clang14-filename 5 "test.c" 0 {
+ "/tmp/cwd"
+} {
+ {"test.c" 0}
+}
+
+## ./test.c
+do_test clang14-dot-filename 5 "test.c" 1 {
+ "/tmp/cwd"
+ "."
+} {
+ {"test.c" 0}
+ {"test.c" 1}
+}
+
+## ../cwd/test.c
+do_test clang14-dot-dot-cwd 5 "../cwd/test.c" 0 {
+ "/tmp/cwd"
+} {
+ {"../cwd/test.c" 0}
+}
+
+## /tmp/cwd/test.c
+do_test clang14-absolute-cwd 5 "/tmp/cwd/test.c" 1 {
+ "/tmp/cwd"
+} {
+ {"/tmp/cwd/test.c" 0}
+ {"test.c" 0}
+}
+
+## ../other/test.c
+do_test clang14-dot-dot-other 5 "../other/test.c" 0 {
+ "/tmp/cwd"
+} {
+ {"../other/test.c" 0}
+}
+
+## /tmp/other/test.c
+do_test clang14-absolute-other 5 "/tmp/other/test.c" 1 {
+ "/tmp/cwd"
+ "/tmp"
+} {
+ {"/tmp/other/test.c" 0}
+ {"other/test.c" 1}
+}
+
+# Based on `gcc -gdwarf-5 -g3 <file>`, gcc 11 paired with gas from binutils
+# 2.34 (Ubuntu 20.04). It generates a v5 .debug_macro section, but a v3
+# .debug_line section.
+
+## test.c
+do_test gcc11-ld234-filename 3 "test.c" 1 {
+} {
+ {"test.c" 0}
+}
+
+## ./test.c
+do_test gcc11-ld234-dot-filename 3 "./test.c" 1 {
+ "."
+} {
+ {"test.c" 1}
+}
+
+## ../cwd/test.c
+do_test gcc11-ld234-dot-dot-cwd 3 "../cwd/test.c" 1 {
+ "../cwd"
+} {
+ {"test.c" 1}
+}
+
+## /tmp/cwd/test.c
+do_test gcc11-ld234-absolute-cwd 3 "/tmp/cwd/test.c" 1 {
+ "/tmp/cwd"
+} {
+ {"test.c" 1}
+}
+
+## ../other/test.c
+do_test gcc11-ld234-dot-dot-other 3 "../other/test.c" 1 {
+ "../other"
+} {
+ {"test.c" 1}
+}
+
+## /tmp/other/test.c
+do_test gcc11-ld234-absolute-other 3 "/tmp/other/test.c" 1 {
+ "/tmp/other"
+} {
+ {"test.c" 1}
+}
diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 55e97c33a6e1..fb62e3ca038d 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -2142,6 +2142,98 @@ namespace eval Dwarf {
incr _debug_loclists_locdesc_count
}
+ # Emit a DWARF .debug_macro section.
+ #
+ # BODY must be Tcl code that emits the content of the section. It is
+ # evaluated in the caller's context. The body can use the `unit` proc
+ # (see `_macro_unit`) to generate macro units.
+
+ proc macro { body } {
+ _section ".debug_macro"
+
+ with_override Dwarf::unit Dwarf::_macro_unit {
+ uplevel $body
+ }
+ }
+
+ # Generate one macro unit.
+ #
+ # This proc is meant to be used within proc macro's body. It is made
+ # available as `unit` while inside proc macro's body.
+ #
+ # BODY must be Tcl code that emits the content of the unit. It may call
+ # procedures defined below, prefixed with `_macro_unit_`, to generate the
+ # unit's content. It is evaluated in the caller's context.
+ #
+ # The `is-64 true|false` options tells whether to use 64-bit DWARF instead
+ # of 32-bit DWARF. The default is 32-bit.
+ #
+ # If specified, the `debug-line-offset-label` option is the name of a label
+ # to use for the unit header's `debug_line_offset` field value. If
+ # omitted, the unit header will not contain the `debug_line_offset` field.
+
+ proc _macro_unit { options body } {
+ parse_options {
+ {"is-64" "false"}
+ {"debug-line-offset-label" ""}
+ }
+
+ _op .2byte 5 "version"
+
+ # Flags:
+ #
+ # offset_size_flag = set if is-64 is true
+ # debug_line_offset_flag = set if debug-line-offset-label is set
+ # opcode_operands_table_flag = 0
+ set flags 0
+
+ if { ${is-64} } {
+ set flags [expr $flags | 0x1]
+ }
+
+ if { ${debug-line-offset-label} != "" } {
+ set flags [expr $flags | 0x2]
+ }
+
+ _op .byte $flags "flags"
+
+ if { ${debug-line-offset-label} != "" } {
+ if { ${is-64} } {
+ _op .8byte ${debug-line-offset-label} "debug_line offset"
+ } else {
+ _op .4byte ${debug-line-offset-label} "debug_line offset"
+ }
+ }
+
+ with_override Dwarf::define Dwarf::_macro_unit_define {
+ with_override Dwarf::start_file Dwarf::_macro_unit_start_file {
+ with_override Dwarf::end_file Dwarf::_macro_unit_end_file {
+ uplevel $body
+ }}}
+ }
+
+ # Emit a DW_MACRO_define entry.
+
+ proc _macro_unit_define { lineno text } {
+ _op .byte 0x1 "DW_MACRO_define"
+ _op .uleb128 $lineno "Line number"
+ _op .asciz "\"$text\"" "Macro definition"
+ }
+
+ # Emit a DW_MACRO_start_file entry.
+
+ proc _macro_unit_start_file { lineno file_idx } {
+ _op .byte 0x3 "DW_MACRO_start_file"
+ _op .uleb128 $lineno
+ _op .uleb128 $file_idx
+ }
+
+ # Emit a DW_MACRO_end_file entry.
+
+ proc _macro_unit_end_file {} {
+ _op .byte 0x4 "DW_MACRO_end_file"
+ }
+
# Emit a DWARF .debug_line unit.
# OPTIONS is a list with an even number of elements containing
# option-name and option-value pairs.
--
2.35.1
^ permalink raw reply [flat|nested] 44+ messages in thread* Re: [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways
2022-04-07 1:51 ` [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways Simon Marchi
@ 2022-04-18 16:53 ` Tom Tromey
2022-04-21 18:36 ` Simon Marchi
0 siblings, 1 reply; 44+ messages in thread
From: Tom Tromey @ 2022-04-18 16:53 UTC (permalink / raw)
To: Simon Marchi via Gdb-patches; +Cc: Simon Marchi, Simon Marchi
>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
Simon> +set out_dir [standard_output_file ""]
Simon> +file mkdir $out_dir/cwd
Simon> +file mkdir $out_dir/other
Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/cwd
Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/other
I never remember exactly but it seems to me that this may need to use
remote_upload?
Simon> +cd $out_dir/cwd
It seems like this will interfere with other tests.
At the very least this test should 'cd' back.
But I wonder if this will work with remote host testing. Or if we even
allow that any more.
Maybe a different approach would be to let the compile command take a
'working directory' parameter.
Tom
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways
2022-04-18 16:53 ` Tom Tromey
@ 2022-04-21 18:36 ` Simon Marchi
2022-04-21 18:45 ` Pedro Alves
0 siblings, 1 reply; 44+ messages in thread
From: Simon Marchi @ 2022-04-21 18:36 UTC (permalink / raw)
To: Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-18 12:53, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Simon> +set out_dir [standard_output_file ""]
> Simon> +file mkdir $out_dir/cwd
> Simon> +file mkdir $out_dir/other
> Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/cwd
> Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/other
>
> I never remember exactly but it seems to me that this may need to use
> remote_upload?
Hmm, don't know. When testing with a remote host, where are the target
programs compiled?
I just checked default_target_compile in DejaGNU, it does execute the
target compiler on the possibly remote host. It uploads the source file
and puts them all in the same default directory on the remote host. So
the test wouldn't make sense then. I think I'll just skip the test if
the host is remote, if that's fine with you.
> Simon> +cd $out_dir/cwd
>
> It seems like this will interfere with other tests.
> At the very least this test should 'cd' back.
>
> But I wonder if this will work with remote host testing. Or if we even
> allow that any more.
I'm not sure anybody does it, because I have never seen fixes regarding
this (and I'm sure there are many cases where we would get it wrong).
>
> Maybe a different approach would be to let the compile command take a
> 'working directory' parameter.
Oh, looks like we have the "with_cwd" proc just for that, I'll use it.
I prefer not to mess with gdb_compile just for a single test, especially
since it's easy to do with with_cwd.
Simon
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways
2022-04-21 18:36 ` Simon Marchi
@ 2022-04-21 18:45 ` Pedro Alves
2022-04-21 18:47 ` Pedro Alves
0 siblings, 1 reply; 44+ messages in thread
From: Pedro Alves @ 2022-04-21 18:45 UTC (permalink / raw)
To: Simon Marchi, Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-21 19:36, Simon Marchi via Gdb-patches wrote:
> On 2022-04-18 12:53, Tom Tromey wrote:
>>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
>>
>> Simon> +set out_dir [standard_output_file ""]
>> Simon> +file mkdir $out_dir/cwd
>> Simon> +file mkdir $out_dir/other
>> Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/cwd
>> Simon> +file copy -force $srcdir/$subdir/$srcfile $out_dir/other
>>
>> I never remember exactly but it seems to me that this may need to use
>> remote_upload?
>
> Hmm, don't know. When testing with a remote host, where are the target
> programs compiled?
On the host.
>
> I just checked default_target_compile in DejaGNU, it does execute the
> target compiler on the possibly remote host. It uploads the source file
> and puts them all in the same default directory on the remote host. So
> the test wouldn't make sense then. I think I'll just skip the test if
> the host is remote, if that's fine with you.
That sounds fine to me.
>
>> Simon> +cd $out_dir/cwd
>>
>> It seems like this will interfere with other tests.
>> At the very least this test should 'cd' back.
>>
>> But I wonder if this will work with remote host testing. Or if we even
>> allow that any more.
>
> I'm not sure anybody does it, because I have never seen fixes regarding
> this (and I'm sure there are many cases where we would get it wrong).
Look up patches from Sandra Loosemore in the last few years. E.g.:
https://sourceware.org/pipermail/gdb-patches/2019-August/159672.html
I don't know whether CodeSourcery uses such a setup for testing Windows, but
I imagine so. When we get to Windows testing, we just might do the same, but
it's still up in the air.
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH 6/6] gdb/testsuite: add macros test for source files compiled in various ways
2022-04-21 18:45 ` Pedro Alves
@ 2022-04-21 18:47 ` Pedro Alves
0 siblings, 0 replies; 44+ messages in thread
From: Pedro Alves @ 2022-04-21 18:47 UTC (permalink / raw)
To: Simon Marchi, Tom Tromey, Simon Marchi via Gdb-patches; +Cc: Simon Marchi
On 2022-04-21 19:45, Pedro Alves wrote:
> I don't know whether CodeSourcery uses such a setup for testing Windows,
I meant, whether STILL uses.
> but I imagine so. When we get to Windows testing, we just might do the same, but
> it's still up in the air.
^ permalink raw reply [flat|nested] 44+ messages in thread