A typical dwarf assembly test-case start like this:
...
standard_testfile .c -debug.S
set asm_file [standard_output_file $srcfile2]
Dwarf::assemble $asm_file {
...
}
if { [prepare_for_testing "failed to prepare" ${testfile} \
[list $srcfile $asm_file] {nodebug}] } {
return -1
}
...
When accidentally using build_for_executable instead of
prepare_for_testing (or intentionally using it but forgetting to add
clean_restart $binfile or some such) the mistake may not be caught, because
another gdb instance is still running, and we may silently end up testing
compiler-generated DWARF.
This can be caused by something relatively obvious, like an earlier
prepare_for_testing or clean_restart, but also by something more obscure like
function_range, which may even be triggered by dwarf assembly like this:
...
{MACRO_AT_func {main}}
...
Fix this by calling gdb_exit at the end of function_range.
Also fix the fallout of that in test-case gdb.dwarf2/dw2-bad-elf.exp, where a
get_sizeof call used the gdb instance left lingering by function_range.
[ A better and more complete fix would add a new proc get_exec_info, that would
be called at the start of the dwarf assembly body:
...
Dwarf::assemble $asm_file {
get_exec_info {main foo} {int void*}
...
that would:
- do a prepare_for_testing with $srcfile (roughtly equivalent to what
MACRO_AT_func does,
- call function_range for all functions main and foo, without starting a
new gdb instance
- set corresponding variables at the call-site: main_start, main_len,
main_end, foo_start, foo_len, foo_end.
- get size for types int and void*
- set corresponding variables at the call-site: int_size, void_ptr_size.
- do a gdb_exit. ]
Tested on x86_64-linux.
It is currently not possible to use variables in locations lists. For
example, with:
diff --git a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
index 6b4f5c8cbb8..cdbf948619f 100644
--- a/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
+++ b/gdb/testsuite/gdb.dwarf2/loclists-multiple-cus.exp
@@ -30,6 +30,8 @@ if {![dwarf2_support]} {
return 0
}
+set myconst 0x123456
+
# Test with 32-bit and 64-bit DWARF.
foreach_with_prefix is_64 {false true} {
if { $is_64 } {
@@ -49,6 +51,7 @@ foreach_with_prefix is_64 {false true} {
global func1_addr func1_len
global func2_addr func2_len
global is_64
+ global myconst
# The CU uses the DW_FORM_loclistx form to refer to the .debug_loclists
# section.
@@ -107,7 +110,7 @@ foreach_with_prefix is_64 {false true} {
list_ {
# When in func1.
start_length $func1_addr $func1_len {
- DW_OP_constu 0x123456
+ DW_OP_constu $myconst
DW_OP_stack_value
}
we get:
$ make check TESTS="*/loclists-multiple-cus.exp"
...
gdb compile failed, build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S: Assembler messages:
build/gdb/testsuite/outputs/gdb.dwarf2/loclists-multiple-cus/loclists-multiple-cus-dw32.S:78: Error: leb128 operand is an undefined symbol: $myconst
...
That means $myconst was copied literally to the generated assembly
file.
This patch fixes it, by running subst on the location list body, in
the context of the caller. The fix is applied to both
Dwarf::loclists::table::list_::start_length and
Dwarf::loclists::table::list_::start_end.
Reported-by: Zoran Zaric <Zoran.Zaric@amd.com>
Change-Id: I615a64431857242d9f477d5699e3732df1b31322
When running gdb.rust/*.exp test-cases with target board unix/-fPIE/-pie, I
run into:
...
builtin_spawn -ignore SIGHUP rustc --color never gdb.rust/watch.rs \
-g -lm -fPIE -pie -o outputs/gdb.rust/watch/watch^M
error: Unrecognized option: 'f'^M
^M
compiler exited with status 1
...
The problem is that -fPIE and -fpie are gcc options, but for rust we use
rustc, which has different compilation options.
Fix this by translating the gcc options to rustc options in gdb_compile_rust,
similar to how that is done for ada in target_compile_ada_from_dir.
Likewise for unix/-fno-PIE/-no-pie.
Tested on x86_64-linux, with:
- native
- unix/-fPIE/-pie
- unix/-fno-PIE/-no-pie
specifically, on openSUSE Leap 15.2 both with package gcc-PIE:
- installed (making gcc default to PIE)
- uninstalled (making gcc default to non-PIE).
and rustc 1.52.1.
Now gdb is capable of debugging executable, which consists of multiple
compilation units (CUs) with the CTF debug info. An executable could
potentially have one or more archives, which, in CTF context, contain
conflicting types.
all changes were made in ctfread.c in which elfctf_build_psymtabs was
modified to handle archives, via the ctf archive iterator and its callback
build_ctf_archive_member and scan_partial_symbols was modified to scan
archives, which are treated as subfiles, to build the psymtabs.
Also changes were made to handle CTF's data object section and function
info section which now share the same format of their contents - an array
of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by
ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries,
which is called by add_stt_obj and add_stt_func when setting up psymtabs
and full symtab, respectively.
When running test-case gdb.dwarf2/dw2-ranges-psym-warning.exp with target
board gnu-debuglink I run into:
...
(gdb) file dw2-ranges-psym-warning^M
Reading symbols from dw2-ranges-psym-warning...^M
Reading symbols from .debug/dw2-ranges-psym-warning.debug...^M
(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym-warning.exp: No complaints
...
Fix this by updating the regexp in gdb_load_no_complaints.
Tested on x86_64-linux.
When running gdb.base/batch-exit-status.exp I noticed that the test name
contains a newline:
...
PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
: No such file or directory\.: [lindex $result 2] == 0
...
Check for this in ::CheckTestNames::check, such that we have a warning:
...
PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
: No such file or directory\.: [lindex $result 2] == 0
WARNING: Newline in test name
...
Tested on x86_64-linux.
The documentation of mi_gdb_test states that the command, pattern and message
arguments are mandatory:
...
# mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb;
# test the result.
...
However, this is not checked, and when mi_gdb_test is called with less than 3
arguments, it passes or fails silently.
Fix this by using the following semantics:
- if there are 1 or 2 arguments, use the command as the message.
- if there is 1 argument, use ".*" as the pattern.
- if there are no or too much arguments, error out.
Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as
message. Fix a few other trivial-looking FAILs.
There are 11 less trivial-looking FAILs left in gdb.mi in test-cases:
- mi-nsmoribund.exp
- mi-breakpoint-changed.exp
- mi-break.exp.
Tested on x86_64-linux.
A regexp pattern with escapes like this is hard to read:
...
set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done"
...
We can make it more readable by spacing out parts (which allows us to also use
the curly braces where that's convenient):
...
set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"]
set re [join $re ""]
...
or by using string_to_regexp:
...
set re [list \
[string_to_regexp {~"$}] \
$decimal \
[string_to_regexp " = 1\\n\"\r\n^done"]]
set re [join $re ""]
...
Note: we have to avoid applying string_to_list to decimal, which is already a
regexp.
Add a proc string_list_to_regexp to make it easy to do both:
...
set re [list \
[string_list_to_regexp ~ {"} $] \
$decimal \
[string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]]
...
Also add a test-case gdb.testsuite/string_to_regexp.exp.
When running the gdb testsuite with gnatmake-4.8, I get many fails of the
following form:
...
gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
compiler exited with status 1
compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
gcc: error: unrecognized command line option '-fgnat-encodings=all'
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
...
Fix this by marking the test unsupported instead, such that we have:
...
UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
(unsupported option '-fgnat-encodings=all')
...
Tested on x86_64-linux.
When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar"
to trigger the internal-error in test-case
gdb.dwarf2/locexpr-data-member-location.exp, we run into:
...
ERROR: couldn't unload file in $gdb (timeout).
...
and the test-case takes about 1 minute.
Fix this by handling internal-error in gdb_unload, such that we have:
...
ERROR: Couldn't unload file in $gdb (GDB internal error).
ERROR: Could not resync from internal error (eof)
...
within 2 seconds.
Tested on x86_64-linux.
When reverting commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: Could not resync from internal error (eof)
...
and takes 1 minute to run.
The long running time is caused by running into a timeout in gdb_run_cmd, at
this point:
...
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
Unexpected type field location kind: 4^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n)
...
Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it
in gdb_run_cmd, but stash the gdb output back into the buffer using
-notransfer, and let the caller proc runto deal with it.
After the fix, the test-case just takes 2 seconds.
Tested on x86_64-linux.
Before commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
}
-re "Create ..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
ERROR: Could not resync from internal error (timeout)
...
Fix the:
...
ERROR: : spawn id exp9 not open
...
by handling eof in gdb_internal_error_resync, such that we have instead:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: Could not resync from internal error (eof)
...
Tested on x86_64-linux.
On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40 vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.
I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68 if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...
Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
and gdb/testsuite/gdb.arch/i386-avx.exp.
Tested on my x86_64-linux laptop with avx support, where both test-cases pass.
gdb/testsuite/ChangeLog:
2021-09-04 Tom de Vries <tdevries@suse.de>
PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here. New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.
This adds support for the half datatype, FP16, to the AVX512 register printing.
gdb/ChangeLog:
2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* i386-tdep.c (i386_zmm_type) <v32_half>: New field.
(i386_ymm_type) <v16_half>: New field.
(i386_gdbarch_init): Add set_gdbarch_half_format.
* features/i386/64bit-avx512.xml: Add half type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add half type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdb.arch/x86-avx512fp16.c: New file.
* gdb.arch/x86-avx512fp16.exp: New file.
* lib/gdb.exp (skip_avx512fp16_tests): New function.
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
...
and similar in gdb.gdb/selftest.exp.
The first FAIL in more detail:
...
(gdb) break captured_main^M
Function "captured_main" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
(got interactive prompt)
...
The problem is that lto has optimized away the captured_main function
and consequently the selftests dependent on that cannot run.
Fix this by:
- using gdb_breakpoint to detect failure to set the breakpoint
- handling the failure to set a breakpoint by calling untested
- not emitting the warning if we've already got untested
such that we have:
...
(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
captured_main, skipping testcase.
...
gdb/testsuite/ChangeLog:
2021-09-02 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp: Emit untested when not being able to set
breakpoint.
The current syntax of proc arange is:
...
proc arange { arange_start arange_length {comment ""} {seg_sel ""} } {
...
and a typical call looks like:
...
arange $start $len
...
This style is somewhat annoying because if you want to specify the last
parameter, you need to give the default values of all the other optional ones
before as well:
...
arange $start $len "" $seg_sel
...
Update the syntax to:
...
proc arange { options arange_start arange_length } {
parse_options {
{ comment "" }
{ seg_sel "" }
}
...
such that a typical call looks like:
...
arange {} $start $len
...
and a call using seg_sel looks like:
...
arange {
seg_sel $seg_sel
} $start $len
...
Also update proc aranges, which already has an options argument, to use the
new proc parse_options.
Tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
A best practise for DWARF [1] is to generate .debug_aranges entries for CUs
even if they have no address range.
Generate .debug_arange entries for the dummy CUs added by the DWARF assembler.
Tested on x86_64-linux.
[1] http://wiki.dwarfstd.org/index.php?title=Best_Practices
Add a proc aranges such that we can generate .debug_aranges sections in dwarf
assembly using:
...
cu { label cu_label } {
...
}
aranges {} cu_label {
arange $addr $len [<comment>] [$segment_selector]
}
...
Tested on x86_64-linux.
We can use current dwarf assembly infrastructure to declare a label that marks
the start of the CU header:
...
declare_labels header_start_cu_a
_section ".debug_info"
header_start_cu_a : cu {} {
}
_section ".debug_info"
header_start_cu_b : cu {} {
}
...
on the condition that we switch to the .debug_info section before, which makes
this style of use fragile.
Another way to achieve the same is to use the label as generated by the cu
proc itself:
...
variable _cu_label
cu {} {
}
set header_start_cu_a $_cu_label
cu {} {
}
set header_start_cu_b $_cu_label
...
but again that seems fragile given that adding a new CU inbetween will
silently result in the wrong value for the label.
Add a label option to proc cu such that we can simply do:
...
cu { label header_start_cu_a } {
}
cu { label header_start_cu_b } {
}
...
Tested on x86_64-linux.
Say one compiles a hello.c:
...
$ gcc -g hello.c
...
On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the
first in .debug_info, nor the last, due to presence of debug information in
objects for sources like:
- ../sysdeps/x86_64/start.S
- init.c
- ../sysdeps/x86_64/crti.S
- elf-init.c
- ../sysdeps/x86_64/crtn.S.
On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the
first and the last in .debug_info.
This difference has caused me to find some errors in the dwarf assembly
using openSUSE, that didn't show up on other platforms.
Force the same situation on other platforms by adding a dummy start
and end CU.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-08-22 Tom de Vries <tdevries@suse.de>
PR testsuite/28235
* lib/dwarf.exp (Dwarf::dummy_cu): New proc.
(Dwarf::assemble): Add dummy start and end CU.
When running test-case gdb.dwarf2/dw2-ranges-psym.exp with target board
-readnow, I run into:
...
(gdb) file dw2-ranges-psym^M
Reading symbols from dw2-ranges-psym...^M
Expanding full symbols from dw2-ranges-psym...^M
(gdb) set complaints 0^M
(gdb) FAIL: gdb.dwarf2/dw2-ranges-psym.exp: No complaints
...
The problem is that the regexp expects a gdb prompt immediately after the
"Reading symbols" line.
Fix this by updating the regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-08-22 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_load_no_complaints): Update regexp to allow
"Expanding full symbols" Line.
This patch addresses a design problem with the symbol_needs_eval_context
class. It exposes the problem by introducing two new testsuite test
cases.
To explain the issue, I first need to explain the dwarf_expr_context
class that the symbol_needs_eval_context class derives from.
The intention behind the dwarf_expr_context class is to commonize the
DWARF expression evaluation mechanism for different evaluation
contexts. Currently in gdb, the evaluation context can contain some or
all of the following information: architecture, object file, frame and
compilation unit.
Depending on the information needed to evaluate a given expression,
there are currently three distinct DWARF expression evaluators:
- Frame: designed to evaluate an expression in the context of a call
frame information (dwarf_expr_executor class). This evaluator doesn't
need a compilation unit information.
- Location description: designed to evaluate an expression in the
context of a source level information (dwarf_evaluate_loc_desc
class). This evaluator expects all information needed for the
evaluation of the given expression to be present.
- Symbol needs: designed to answer a question about the parts of the
context information required to evaluate a DWARF expression behind a
given symbol (symbol_needs_eval_context class). This evaluator
doesn't need a frame information.
The functional difference between the symbol needs evaluator and the
others is that this evaluator is not meant to interact with the actual
target. Instead, it is supposed to check which parts of the context
information are needed for the given DWARF expression to be evaluated by
the location description evaluator.
The idea is to take advantage of the existing dwarf_expr_context
evaluation mechanism and to fake all required interactions with the
actual target, by returning back dummy values. The evaluation result is
returned as one of three possible values, based on operations found in a
given expression:
- SYMBOL_NEEDS_NONE,
- SYMBOL_NEEDS_REGISTERS and
- SYMBOL_NEEDS_FRAME.
The problem here is that faking results of target interactions can yield
an incorrect evaluation result.
For example, if we have a conditional DWARF expression, where the
condition depends on a value read from an actual target, and the true
branch of the condition requires a frame information to be evaluated,
while the false branch doesn't, fake target reads could conclude that a
frame information is not needed, where in fact it is. This wrong
information would then cause the expression to be actually evaluated (by
the location description evaluator) with a missing frame information.
This would then crash the debugger.
The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this
scenario, with the following DWARF expression:
DW_OP_addr $some_variable
DW_OP_deref
# conditional jump to DW_OP_bregx
DW_OP_bra 4
DW_OP_lit0
# jump to DW_OP_stack_value
DW_OP_skip 3
DW_OP_bregx $dwarf_regnum 0
DW_OP_stack_value
This expression describes a case where some variable dictates the
location of another variable. Depending on a value of some_variable, the
variable whose location is described by this expression is either read
from a register or it is defined as a constant value 0. In both cases,
the value will be returned as an implicit location description on the
DWARF stack.
Currently, when the symbol needs evaluator fakes a memory read from the
address behind the some_variable variable, the constant value 0 is used
as the value of the variable A, and the check returns the
SYMBOL_NEEDS_NONE result.
This is clearly a wrong result and it causes the debugger to crash.
The scenario might sound strange to some people, but it comes from a
SIMD/SIMT architecture where $some_variable is an execution mask. In
any case, it is a valid DWARF expression, and GDB shouldn't crash while
evaluating it. Also, a similar example could be made based on a
condition of the frame base value, where if that value is concluded to
be 0, the variable location could be defaulted to a TLS based memory
address.
The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second
scenario. This scenario is a bit more abstract due to the DWARF
assembler lacking the CFI support, but it exposes a different
manifestation of the same problem. Like in the previous scenario, the
DWARF expression used in the test is valid:
DW_OP_lit1
DW_OP_addr $some_variable
DW_OP_deref
# jump to DW_OP_fbreg
DW_OP_skip 4
DW_OP_drop
DW_OP_fbreg 0
DW_OP_dup
DW_OP_lit0
DW_OP_eq
# conditional jump to DW_OP_drop
DW_OP_bra -9
DW_OP_stack_value
Similarly to the previous scenario, the location of a variable A is an
implicit location description with a constant value that depends on a
value held by a global variable. The difference from the previous case
is that DWARF expression contains a loop instead of just one branch. The
end condition of that loop depends on the expectation that a frame base
value is never zero. Currently, the act of faking the target reads will
cause the symbol needs evaluator to get stuck in an infinite loop.
Somebody could argue that we could change the fake reads to return
something else, but that would only hide the real problem.
The general impression seems to be that the desired design is to have
one class that deals with parsing of the DWARF expression, while there
are virtual methods that deal with specifics of some operations.
Using an evaluator mechanism here doesn't seem to be correct, because
the act of evaluation relies on accessing the data from the actual
target with the possibility of skipping the evaluation of some parts of
the expression.
To better explain the proposed solution for the issue, I first need to
explain a couple more details behind the current design:
There are multiple places in gdb that handle DWARF expression parsing
for different purposes. Some are in charge of converting the expression
to some other internal representation (decode_location_expression,
disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are
analysing the expression for specific information
(compute_stack_depth_worker) and some are in charge of evaluating the
expression in a given context (dwarf_expr_context::execute_stack_op
and decode_locdesc).
The problem is that all those functions have a similar (large) switch
statement that handles each DWARF expression operation. The result of
this is a code duplication and harder maintenance.
As a step into the right direction to solve this problem (at least for
the purpose of a DWARF expression evaluation) the expression parsing was
commonized inside of an evaluator base class (dwarf_expr_context). This
makes sense for all derived classes, except for the symbol needs
evaluator (symbol_needs_eval_context) class.
As described previously the problem with this evaluator is that if the
evaluator is not allowed to access the actual target, it is not really
evaluating.
Instead, the desired function of a symbol needs evaluator seems to fall
more into expression analysis category. This means that a more natural
fit for this evaluator is to be a symbol needs analysis, similar to the
existing compute_stack_depth_worker analysis.
Another problem is that using a heavyweight mechanism of an evaluator
to do an expression analysis seems to be an unneeded overhead. It also
requires a more complicated design of the parent class to support fake
target reads.
The reality is that the whole symbol_needs_eval_context class can be
replaced with a lightweight recursive analysis function, that will give
more correct result without compromising the design of the
dwarf_expr_context class. The analysis treats the expression byte
stream as a DWARF operation graph, where each graph node can be
visited only once and each operation can decide if the frame context
is needed for their evaluation.
The downside of this approach is adding of one more similar switch
statement, but at least this way the new symbol needs analysis will be
a lightweight mechnism and it will provide a correct result for any
given DWARF expression.
A more desired long term design would be to have one class that deals
with parsing of the DWARF expression, while there would be a virtual
methods that deal with specifics of some DWARF operations. Then that
class would be used as a base for all DWARF expression parsing mentioned
at the beginning.
This however, requires a far bigger changes that are out of the scope
of this patch series.
The new analysis requires the DWARF location description for the
argc argument of the main function to change in the assembly file
gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression
ended with a 0 value byte, which was never reached by the symbol needs
evaluator, because it was detecting a stack underflow when evaluating
the operation before. The new approach does not simulate a DWARF
stack anymore, so the 0 value byte needs to be removed because it
makes the DWARF expression invalid.
gdb/ChangeLog:
* dwarf2/loc.c (class symbol_needs_eval_context): Remove.
(dwarf2_get_symbol_read_needs): New function.
(dwarf2_loc_desc_get_symbol_read_needs): Remove.
(locexpr_get_symbol_read_needs): Use
dwarf2_get_symbol_read_needs.
gdb/testsuite/ChangeLog:
* gdb.python/amd64-py-framefilter-invalidarg.S : Update argc
DWARF location expression.
* lib/dwarf.exp (_location): Handle DW_OP_fbreg.
* gdb.dwarf2/symbol_needs_eval.c: New file.
* gdb.dwarf2/symbol_needs_eval_fail.exp: New file.
* gdb.dwarf2/symbol_needs_eval_timeout.exp: New file.
In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
last_spawn_tty_name depending on whether spawn_out(slave,name) exists
or not.
One situation that might cause spawn_out(slave,name) to not exists is
if the spawn function is called with the argument -leaveopen, which is
how it is called when processes are created as part of a pipeline, the
created process has no tty, instead its output is written to a file
descriptor.
If a pipeline is created consisting of multiple processes then there
will be multiple sequential calls to spawn, all using -leaveopen. The
first of these calls is fine, spawn_out(slave,name) is not set, and so
in spawn_capture_tty_name we unset last_spawn_tty_name. However, on
the second call to spawn, spawn_out(slave,name) is still not set and
so in spawn_capture_tty_name we again try to unset
last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
is already unset).
Fix this issue by using -nocomplain with the call to unset in
spawn_capture_tty_name.
Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
pass, and 1 unsupported test. After this commit I now see 16 passes
from this test script.
I have also improved the code that used to do this:
if { [info exists spawn_out] } {
set ::last_spawn_tty_name $spawn_out(slave,name)
} else {
...
}
The problem here is that we check for the existence of spawn_out, and
then unconditionally read spawn_out(slave,name). A situation could
arise where some other element of spawn_out is set,
e.g. spawn_out(foo), in which case we would enter the if block and try
to read a non-existent variable. After this commit we now check
specifically for spawn_out(slave,name).
Finally, it is worth noting that before this issue was fixed runtest
itself, or rather the expect process behind runtest, would segfault
while exiting. I haven't looked at all into what the problem is here
that caused expect to crash, as fixing the bug in GDB's testing
scripts made the segfault go away.
When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
(gdb) ptype/o static_member^M
/* offset | size */ type = struct static_member {^M
- static static_member Empty;^M
/* 0 | 4 */ int abc;^M
^M
/* total size (bytes): 4 */^M
}^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...
This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".
It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-20 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.
Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on
riscv64-linux-gnu. Those tests check that when stepping, if the
debuggee received a signal it should step inside the signal handler.
This feature requires hardware support for single stepping (or at least
kernel support), but none are available on riscv*-linux-gnu hosts, at
the moment at least.
This patch adds RISC-V to the list of configurations that does not
have hardware single step capability, disabling tests relying on such
feature.
Tested on riscv64-linux-gnu.
When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
I run into:
...
FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
...
This is due to a dummy .gdb_index:
...
Contents of the .gdb_index section:
Version 7
CU table:
TU table:
Address table:
Symbol table:
...
The dummy .gdb_index is ignored when loading the symbols, and instead partial
symbols are used. Consequently, we get the same result as if we'd removed
-Wl,--gdb-index from the compilation.
Presumably, gold fails to generate a proper .gdb_index because it lacks
DWARF5 support.
Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
trying to excercise. Fix this by detecting whether we actually used a
.gdb_index for symbol loading.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (have_index): New proc.
* gdb.base/gold-gdb-index.exp: Use have_index.
When running test-case gdb.mi/mi-info-sources.exp, I run into:
...
Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ...
ERROR: internal buffer is full.
...
due to extra debug info from the shared libraries.
Fix this by using "nosharedlibrary".
Then I run into these FAILs:
...
FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \
-file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files --group-by-objfile, look for \
mi-info-sources.c (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files --group-by-objfile, look for \
mi-info-sources-base.c (unexpected output)
...
due to openSUSE executables which have debug info for objects from sources
like sysdeps/x86_64/crtn.S.
Fix these by updating the patterns, and adding "maint expand-symtabs" to
reliably get fully-read objfiles.
Then I run into FAILs when using the readnow target board. Fix these by
skipping the relevant tests.
Then I run into FAILs when using the cc-with-gnu-debuglink board. Fix these
by updating the patterns.
Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index,
cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m.
gdb/testsuite/ChangeLog:
2021-07-05 Tom de Vries <tdevries@suse.de>
* lib/mi-support.exp (mi_readnow): New proc.
* gdb.mi/mi-info-sources.exp: Use nosharedlibrary. Update patterns.
Skip tests for readnow. Use "maint expand-symtabs".
Currently, if you run make check-perf on a system with Python 3.8,
tests seen to PASS, but they actually test a lot less than intended,
due to:
PerfTest::assemble, run ...
python BackTrace(64).run()
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
self.execute_test()
File "<string>", line 49, in execute_test
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
m.start(id)
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
self.start_time = time.clock()
AttributeError: module 'time' has no attribute 'clock'
Error while executing Python code.
(gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run()
And then, after fixing the above Python compatibility issues (which
will be a separate patch), I get 86 instances of overflowing expect's
buffer, like:
ERROR: internal buffer is full.
UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run()
This patch fixes both problems by adding & using a gdb_test_python_run
routine that:
- checks for Python errors
- consumes output line by line
gdb/testsuite/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* gdb.perf/backtrace.exp: Use gdb_test_python_run.
* gdb.perf/disassemble.exp: Use gdb_test_python_run.
* gdb.perf/single-step.exp: Use gdb_test_python_run.
* gdb.perf/skip-command.exp: Use gdb_test_python_run.
* gdb.perf/skip-prologue.exp: Use gdb_test_python_run.
* gdb.perf/solib.exp: Use gdb_test_python_run.
* gdb.perf/template-breakpoints.exp: Use gdb_test_python_run.
* lib/perftest.exp (gdb_test_python_run): New.
Change-Id: I007af36f164b3f4cda41033616eaaa4e268dfd2f
At the moment some check-read1 timeouts are handled like this in
gdb.base/info-macros.exp:
...
gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname {
-re "$r1$r2$r3" {
pass $testname
}
-re ".*#define TWO.*\r\n$gdb_prompt" {
fail $testname
}
-re ".*#define THREE.*\r\n$gdb_prompt" {
fail $testname
}
-re ".*#define FOUR.*\r\n$gdb_prompt" {
fail $testname
}
}
...
which is not ideal.
We could use gdb_test_lines, but it currently doesn't support verifying
the absence of regexps, which is done using the clauses above calling fail.
Fix this by using gdb_test_lines and adding a -re-not syntax to
gdb_test_lines, such that we can do:
...
gdb_test_lines $test $testname $r1.*$r2 \
-re-not "#define TWO" \
-re-not "#define THREE" \
-re-not "#define FOUR"
...
Tested on x86_64-linux, whith make targets check and check-read1.
Also observed that check-read1 execution time is reduced from 6m35s to 13s.
gdb/testsuite/ChangeLog:
2021-07-06 Tom de Vries <tdevries@suse.de>
* gdb.base/info-macros.exp: Replace use of
gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines.
(gdb_test_multiple_with_read1_timeout_factor): Remove.
* lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>.
When GCC emits .debug_aranges, it adds padding to align the contents
to two times the address size. GCC has done this for many years --
but there is nothing in the DWARF standard that says this should be
done, and LLVM does not seem to add this padding.
It's simple to detect if the padding exists, though: if the contents
of one .debug_aranges CU (excluding the header) are not a multiple of
the alignment that GCC uses, then anything extra must be padding.
This patch changes gdb to correctly read both styles. It removes the
requirement that the padding bytes be zero, as this seemed
unnecessarily pedantic to me.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (create_addrmap_from_aranges): Change padding
logic.
gdb/testsuite/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): Add "style"
parameter.
* gdb.rust/dwindex.exp: New file.
* gdb.rust/dwindex.rs: New file.
This patch adds a file with the ISA 3.1 check. The ISA 3.1 check is
added to the test to ensure the test is only run on ISA 3.1 or newer.
gdb/testsuite/ChangeLog
2021-06-25 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-plxv-norel.exp: Add call to skip_power_isa_3_1_tests.
* lib/gdb.exp(skip_power_isa_3_1_tests): New gdb_caching_proc test.
On Ubuntu 20.04, when the debug info package for libc is not installed,
I get:
FAIL: gdb.base/info-types-c++.exp: info types
FAIL: gdb.base/info-types-c.exp: info types
The reason is that the output of info types is exactly:
(gdb) info types
All defined types:
File /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
52: typedef enum {...} anon_enum_t;
45: typedef struct {...} anon_struct_t;
68: typedef union {...} anon_union_t;
28: typedef struct baz_t baz;
31: typedef struct baz_t * baz_ptr;
21: struct baz_t;
double
33: enum enum_t;
float
int
38: typedef enum enum_t my_enum_t;
17: typedef float my_float_t;
16: typedef int my_int_t;
54: typedef enum {...} nested_anon_enum_t;
47: typedef struct {...} nested_anon_struct_t;
70: typedef union {...} nested_anon_union_t;
30: typedef struct baz_t nested_baz;
29: typedef struct baz_t nested_baz_t;
39: typedef enum enum_t nested_enum_t;
19: typedef float nested_float_t;
18: typedef int nested_int_t;
62: typedef union union_t nested_union_t;
56: union union_t;
unsigned int
(gdb)
The lines we expect in the test contain an empty line at the end:
...
"62:\[\t \]+typedef union union_t nested_union_t;" \
"56:\[\t \]+union union_t;" \
"--optional" "\[\t \]+unsigned int" \
""]
This is written with the supposition that other files will be listed, so
an empty line will be included to separate the symbols from this file
from the next one. This empty line is not included when info-types.c is
the only file listed.
Fix this by rewriting gdb_test_lines to accept a single, plain tcl multiline
regexp, such that we can write:
...
"62:\[\t \]+typedef union union_t nested_union_t;" \
"56:\[\t \]+union union_t;(" \
"\[\t \]+unsigned int)?" \
"($|\r\n.*)"]
...
Tested affected test-cases:
- gdb.base/info-types-c.exp
- gdb.base/info-types-c++.exp
- gdb.base/info-macros.exp
- gdb.cp/cplusfuncs.exp
on x86_64-linux (openSUSE Leap 15.2), both with check and check-read1.
Also tested the first two with gcc-4.8.
Also tested on ubuntu 18.04.
gdb/testsuite/ChangeLog:
2021-06-23 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_lines): Rewrite to accept single
multiline tcl regexp.
* gdb.base/info-types.exp.tcl: Update. Make empty line at end of
regexp optional.
* gdb.base/info-macros.exp: Update.
* gdb.cp/cplusfuncs.exp: Update.
Without that it is impossible to debug on riscv64.
gdb/
PR symtab/27999
* dwarf2/loc.c (decode_debug_loclists_addresses): Support
DW_LLE_start_end.
gdb/testsuite/
PR symtab/27999
* lib/dwarf.exp (start_end): New proc inside loclists.
* gdb.dwarf2/loclists-start-end.exp: New file.
* gdb.dwarf2/loclists-start-end.c: New file.
I finally found time to teach readelf to identify PIEs in the file
header display and program header display. So in place of
"DYN (Shared object file)" which isn't completely true, show
"DYN (Position-Independent Executable file)".
It requires a little bit of untangling code in readelf due to
process_program_headers setting up dynamic_addr and dynamic_size,
needed to scan .dynamic for the DT_FLAGS_1 entry, and
process_program_headers itself wanting to display the file type in
some cases. At first I modified process_program_header using a
"probe" parameter similar to get_section_headers in order to inhibit
output, but decided it was cleaner to separate out
locate_dynamic_sections.
binutils/
* readelf.c (locate_dynamic_section, is_pie): New functions.
(get_file_type): Replace e_type parameter with filedata. Call
is_pie for ET_DYN. Update all callers.
(process_program_headers): Use local variables dynamic_addr and
dynamic_size, updating filedata on exit from function. Set
dynamic_size of 1 to indicate no dynamic section or segment.
Update tests of dynamic_size throughout.
* testsuite/binutils-all/x86-64/pr27708.dump: Update expected output.
ld/
* testsuite/ld-pie/vaddr-0.d: Update expected output.
gdb/
* testsuite/lib/gdb.exp (exec_is_pie): Match new PIE readelf output.
This patch implements Rust raw identifiers in the lexer in gdb. There
was an earlier patch to do this, but the contributor didn't reply to
my email asking whether he had sorted out his copyright assignment.
This is relatively straightforward, but a small test suite addition
was needd to ensure that the new test is skipped on older versions of
rustc -- ones that predate the introduction of raw identifiers.
gdb/ChangeLog
2021-06-11 Tom Tromey <tom@tromey.com>
PR rust/23427
* rust-parse.c (rust_parser::lex_identifier): Handle raw
identifiers.
(rust_lex_tests): Add raw identifier tests.
gdb/testsuite/ChangeLog
2021-06-11 Tom Tromey <tom@tromey.com>
PR rust/23427
* lib/rust-support.exp (rust_compiler_version): New caching proc.
* gdb.rust/rawids.exp: New file.
* gdb.rust/rawids.rs: New file.
The TUI test gdb.tui/empty.exp fails with the native-extended-gdbserver
board, and takes a very long time to run due to numerous timeouts. The
symptom, when looking at the logs, is that the TUI windows that we
expect to be resized are not resized. Digging down, I found that GDB
didn't receive any SIGWINCH that should have resulted from
Term::resize's stty calls.
The reason for this is:
- The native-extended-gdbserver overrides gdb_start to first start GDB,
then start GDBserver with --multi, then connect GDB to GDBserver.
This means that two TCL "spawn"s are done, one for GDB and one for
GDBserver.
- The TUI test framework wants to know GDB's TTY name, so it can pass
it to stty, to fake terminal resizes. To do so, it overrides the
spawn built-in proc to capture the tty name from the internals of the
built-in proc. It saves the TTY name to the gdb_spawn_name global
variable.
- Because the native-extended-gdbserver boards starts both GDB and
GDBserver, the final value of gdb_spawn_name is the name of
GDBserver's TTY.
- When the TUI test framework attempts to resize GDB's terminal, it in
fact resizes GDBserver's terminal. So obviously, GDB doesn't get the
SIGWINCH, and we don't get the expected TUI redraw.
Fix that by moving the hack to lib/gdb.exp, overriding the builtin spawn
all the time. The override saves the TTY name in the
last_spawn_tty_name global. The default_gdb_spawn proc then saves it in
the gdb_tty_name global. This way, we specifically capture GDB's TTY
name in gdb_tty_name, not the TTY name of other spawned processes.
Remove tuiterm_env_init and tuiterm_env_finish, since they are now
empty. In turn, the gdb_finish_hooks mechanism is now unused, remove it
as well. It would be easy to add them back if needed.
gdb/ChangeLog:
* lib/gdb.exp (default_gdb_exit): Unset gdb_tty_name.
(spawn_capture_tty_name): New, override builtin spawn.
(default_gdb_spawn): Capture GDB's TTY name.
* lib/tuiterm.exp (tuiterm_spawn): Remove.
(tuiterm_env_init, tuiterm_env_finish): Remove spawn override.
(Term) <resize>: Use new variable name.
(tuiterm_env_init, tuiterm_env_finish): Remove.
(tuiterm_env): Don't call tuiterm_env_init and register
tuiterm_env_finish in gdb_finish_hooks.
(gdb_finish_hooks): Remove.
(gdb_finish): Don't call finish hooks.
Change-Id: Ia5ab74184a52a996416022308f8d0cc523355a78
With check-read1 I occasionally run into:
...
FAIL: gdb.cp/nested-types.exp: ptype S10 (limit = 7) \
// parse failed (timeout)
...
I can trigger this reliably by running check-read1 in conjunction with
stress -c 5.
Fix this by breaking up the regexp in cp_test_ptype_class.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-10 Tom de Vries <tdevries@suse.de>
* lib/cp-support.exp (cp_test_ptype_class): Break up regexp.
* gdb.cp/nested-types.exp: Remove usage of read1 timeout factor.
I was diagnosing some problem with a TUI test case, which lead me to
improve the logging of _check_box a bit. It did help me, so I think it
would be nice to have it upstream.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (Term) <_check_box>: Improve logging.
Change-Id: I887e83c02507d6c59c991e17f795c844ed63bacf
It's a common mistake of mine to do:
...
set l [list "foo" "bar"]
set re [multi_line $l]
...
and to get "foo bar" while I was expecting "foo\r\nbar", which I get after
doing instead:
...
set re [multi_line {*}$l]
...
Detect this type of mistake by erroring out in multi_line when only one
argument is passed.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-08 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (multi_line): Require more than one argument.
* gdb.base/gdbinit-history.exp: Update multi_line call.
* gdb.base/jit-reader.exp: Remove multi_line call.
* gdb.fortran/dynamic-ptype-whatis.exp: Same.
With check-read1 we run into:
...
FAIL: gdb.base/info-macros.exp: info macros info-macros.c:42 (timeout)
...
Fix this by using gdb_test_lines from gdb.base/info-types.exp.tcl.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-06-08 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp.tcl (match_line, gdb_test_lines): Move ...
* lib/gdb.exp: ... here.
* gdb.base/info-macros.exp: Use gdb_test_lines.
We currently make use of the -J option to gfortran in order that
compiled modules should be placed in the correct output directory.
Obviously different compilers, e.g. flang, will have different options
to achieve the same result.
This commit makes it so we only add the -J flag when using a gcc
based (i.e. gfortran) compiler.
I had a look through the flang help page and tried a few likely
looking options, but couldn't find anything that seemed to do the same
thing, so, for now, I'm only adding an extra option when compiling
with gfortran.
This does mean that any compiler other than gfortran might run into
problems if running the testsuite in parallel due to modules of the
same name all being written to the same directory, and so possibly
overwriting each other.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Only add the -J option when using a
gcc based Fortran compiler, for example, flang does not support
this option.
One of the integer type patterns used by flang included a '*'
character which was not escaped.
gdb/testsuite/ChangeLog:
* lib/fortran.exp (fortran_int8): Escape '*' in pattern.
The guile support library has some "tests" that are actually being
used to setup GDB ready for the real guile tests, e.g. we load some
support modules, and define some helper functions.
As this setup is done every time we call gdb_guile_runto_main, which
could be called multiple times in a single test script, this can lead
to duplicate PASS lines.
As this setup is all pretty basic, and isn't the actual focus of the
real tests, then in this commit I pass an empty test name through to
the gdb_test_no_output calls, the result of this is that the PASS
lines are no longer printed. This removes some duplicate tests from
the gdb.guile/*.exp set of tests.
gdb/testsuite/ChangeLog:
* lib/guile.exp (gdb_scm_load_file): Use empty test name to
silence PASS lines.
(gdb_install_guile_module): Likewise.
Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into:
...
FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout)
FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout)
...
The commit adds this line in proc vgdb_start:
...
set vgdbcmd "set remotetimeout 3"
...
which has no effect given that the value of var vgdbcmd is not used before
it's overwritten. We can fix this by doing instead:
...
set_remotetimeout 3
...
The FAIL I'm observing is fixed by increasing the remotetimeout value to 4.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-29 Tom de Vries <tdevries@suse.de>
PR testsuite/27786
* lib/valgrind.exp (vgdb_start): Use set_remotetimeout. Increase
remotetimeout to 4.
I'm seeing timeouts from gdb.rust/traits.exp when we attempt to print
things with "maint print objfiles".
This happens for two reasons:
1 - GDB does not explicitly split each entry into its own line, but rather
relies on the terminal's width to insert line breaks.
2 - When running the GDB testsuite, such width may be unlimited, which will
prevent GDB from inserting any line breaks.
As a result, the output may be too lengthy and will come in big lines. Tweak
the support library to match the patterns line-by-line, which gives us more
time to match things. Also fix GDB's output to print one entry per line,
regardless of the terminal width.
A similar approach was used in another testcase using the same command (commit
eaeaf44cfdc9a4096a0dd52fa0606f29d4bfd48e). With the new line breaks, we don't
need a particular pattern, so clean up that test as well.
gdb/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* psymtab.c (psymbol_functions::dump): Output newline.
* symmisc.c (dump_objfile): Likewise.
gdb/testsuite/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* gdb.base/maint.exp: Drop a pattern that is not needed.
* lib/gdb.exp (readnow): Match line-by-line.
Adds the ability to process commands at a new phase during GDB's
startup. This phase is earlier than the current initialisation file
processing, before GDB has produced any output.
The number of commands that can be processed at this early stage will
be limited, and it is expected that the only commands that would be
processed at this stage will relate to some of the fundamentals of how
GDB starts up.
Currently the only commands that it makes sense to add to this early
initialization file are those like 'set style version ....' as the
version string is displayed during startup before the standard
initialization files are parsed. As such this commit fully resolved
bug cli/25956.
This commit adds a mechanism to execute these early initialization
files from a users HOME directory, as well as some corresponding
command line flags for GDB.
The early initialization files that GDB will currently check for are
~/.config/gdb/gdbearlyinit (on Linux like systems) or ~/.gdbearlyinit
if the former is not found.
The output of 'gdb --help' has been extended to include a list of the
early initialization files being processed.
gdb/ChangeLog:
PR cli/25956
* NEWS: Mention new early init files and command line options.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Define GDBEARLYINIT.
* main.c (get_earlyinit_files): New function.
(enum cmdarg_kind): Add CMDARG_EARLYINIT_FILE and
CMDARG_EARLYINIT_COMMAND.
(captured_main_1): Add support for new command line flags, and for
processing startup files.
(print_gdb_help): Include startup files in the output.
gdb/doc/ChangeLog:
PR cli/25956
* gdb.texinfo (File Options): Mention new command line options.
(Startup): Discuss when early init files are processed.
(Initialization Files): Add description of early init files.
(Output Styling): Update description of 'version' style.
(gdb man): Mention early init files.
gdb/testsuite/ChangeLog:
PR cli/25956
* gdb.base/early-init-file.c: New file.
* gdb.base/early-init-file.exp: New file.
* lib/gdb-utils.exp (style): Handle style 'none'.
This commit fixes fission support in the Dwarf assembler. I added the
new test gdb.dwarf2/fission-absolute-dwo.exp which is a simple example
of using the fission support. I also rewrote the existing test
gdb.dwarf2/fission-multi-cu.exp to use the new functionality (instead
of using an x86-64 only assembler file).
To better support compiling the assembler files produced by the Dwarf
assembler I have added the new proc build_executable_and_dwo_files in
lib/dwarf.exp, this replaces build_executable_from_fission_assembler,
all the tests that used the old proc have been updated. Where the old
proc assumed a single .S source file which contained the entire test,
the new proc allows for multiple source files.
The Dwarf assembler already had some fission support, however, this
was not actually used in any tests, and when I tried using it there
were a few issues.
The biggest change is that we now generate DW_FORM_GNU_addr_index
instead of DW_FORM_addr for the low and high pc in
_handle_macro_at_range, support for the DW_FORM_GNU_addr_index is new
in this commit.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/fission-absolute-dwo.c: New file.
* gdb.dwarf2/fission-absolute-dwo.exp: New file.
* gdb.dwarf2/fission-base.exp: Use build_executable_and_dwo_files
instead of build_executable_from_fission_assembler.
* gdb.dwarf2/fission-loclists-pie.exp: Likewise.
* gdb.dwarf2/fission-loclists.exp: Likewise.
