This commit adds the gdb_caching_proc, support_nested_function_tests,
to lib/gdb.exp. It tests to see whether or not the C compiler has
support for nested function calls.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (support_nested_function_tests): New proc.
Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the
Fotran compile produces .mod files. These files contain details of
compiled modules that are then consumed by the compiler when compiling
other files that USE a module.
Currently the compiler writes the .mod files into its current
directory, so for us this turns out to be 'build/gdb/testsuite/'.
This means that .mod files can be shared between tests, which seems
against the spirit of the GDB testsuite; source files should be
compiled fresh for each test.
This commit adds the -J option to the compiler flags whenever we
compile a Fortran file, this option tells the compiler where to write,
and look for, .mod files.
After this commit there was one Fortran test that needed fixing, with
that fix in place all of the Fortran tests pass again, but now the
.mod files are now produced in the per-test output directories.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Add -J compiler option when building
Fortran tests.
* gdb.mi/mi-fortran-modules.exp: Compile source files in correct
order.
Change-Id: I99444cf22d80e320093d3f3ed9abb8825f378e0b
The two guard functions skip_btrace_tests and skip_btrace_pt_tests
have a minor bug, if the check function fails to compile then surely
we should skip the btrace tests - currently we return 0 to indicate
don't skip.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_btrace_tests): Return 1 if the test fails to
compile.
(skip_btrace_pt_tests): Likewise.
Change-Id: I6dfc04b4adcf5b9424fb542ece7ddbe751bee301
Most versions of GCC in the wild don't support CTF debug format right
now, so, rather than attempting to compile the tests and failing each
time, this patch introduces a guard function to check if the compiler
supports CTF. If we don't have CTF support then the CTF tests are
skipped.
This patch only updates 3 of the 4 CTF tests, the fourth will be
handled in the next patch.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-constvars.exp: Skip test if CTF is not supported in
the compiler. Clean up header comment a little.
* gdb.base/ctf-ptype.exp: Likewise.
* gdb.base/ctf-whatis.exp: Likewise.
* lib/gdb.exp (skip_ctf_tests): New proc.
Change-Id: I505c11169a9bc9871a31fc0c61e119f92f32cc63
Proc gdb_test_multiple builds up and executes a gdb_expect expression with
pattern/action clauses. The clauses are either implicit (added by
gdb_test_multiple) or explicit (passed via the gdb_test_multiple parameter
user_code).
However, there are a few implicit clauses which are inserted before the
explicit ones, making sure those take precedence.
Add an -early pattern flag for a gdb_test_multiple user_code clause to specify
that the clause needs to be inserted before any implicit clause.
Using this pattern flag, we can f.i. setup a kfail for an assertion failure
<assert> during gdb_continue_to_breakpoint by the rewrite:
...
gdb_continue_to_breakpoint <msg> <pattern>
...
into:
...
set breakpoint_pattern "(?:Breakpoint|Temporary breakpoint) .* (at|in)"
gdb_test_multiple "continue" "continue to breakpoint: <msg>" {
-early -re "internal-error: <assert>" {
setup_kfail gdb/nnnnn "*-*-*"
exp_continue
}
-re "$breakpoint_pattern <pattern>\r\n$gdb_prompt $" {
pass $gdb_test_name
}
}
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-30 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Handle -early pattern flag.
Change-Id: I376c636b0812be52e7137634b1a4f50bf2b999b6
Currently, in order to rewrite:
...
gdb_test <command> <pattern> <message>
...
using gdb_test_multiple, we get:
...
gdb_test_multiple <command> <message> {
-re "\[\r\n\]*(?:<pattern>)\[\r\n\]+$gdb_prompt $" {
pass $gdb_test_name
}
}
...
Add a '-wrap pattern flag to gdb_test_multiple, that wraps the regexp
pattern as gdb_test wraps its message argument.
This allows us to rewrite into the more compact:
...
gdb_test_multiple <command> <message> {
-re -wrap <pattern> {
pass $gdb_test_name
}
}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Add -wrap pattern flag.
* gdb.reverse/step-precsave.exp: Rewrite gdb_test_multiple containing
kfail using -wrap pattern flag and convenience variable
gdb_test_name.
Change-Id: Ie42c97d5ab7acf6db351299ccd23a83540fe6e1a
Normally the gdb.reverse/*.exp test-cases pass on my system (apart from the
record/23188 KFAIL for gdb.reverse/step-precsave.exp). But when specifying
GLIBC_TUNABLES=glibc.tune.hwcaps=-XSAVEC_Usable to force glibc to use
_dl_runtime_resolve_xsave instead of _dl_runtime_resolve_xsavec, we run into
1054 FAILs like this:
...
(gdb) PASS: gdb.reverse/sigall-reverse.exp: b gen_HUP
continue^M
Continuing.^M
Process record does not support instruction 0xfae64 at address \
0x7ffff7ded958.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7ded958 in _dl_runtime_resolve_xsave () from \
/lib64/ld-linux-x86-64.so.2^M
(gdb) FAIL: gdb.reverse/sigall-reverse.exp: get signal ABRT
...
The problem is that the xsave instruction is not supported in
reverse-debugging (PR record/25038).
Add KFAILs for this PR.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-13 Tom de Vries <tdevries@suse.de>
PR record/25038
* gdb.reverse/sigall-precsave.exp: Add PR record/25038 KFAIL.
* gdb.reverse/sigall-reverse.exp: Same.
* gdb.reverse/solib-precsave.exp: Same.
* gdb.reverse/solib-reverse.exp: Same.
* gdb.reverse/step-precsave.exp: Same.
* gdb.reverse/until-precsave.exp: Same.
* gdb.reverse/until-reverse.exp: Same.
* lib/gdb.exp (gdb_continue_to_breakpoint): Same.
This commit adds a new feature to gdb_test_multiple, an automatically
created variable gdb_test_name. The idea is to make it easier to
write tests using gdb_test_multiple, and avoid places where the string
passed to pass/fail within an action element is different to the
message passed to the top level gdb_test_multiple.
As an example, previously you might write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass "test foo"
}
-re "expected output 2" {
fail "test foo"
}
}
This is OK, but it's easy for the pass/fail strings to come out of
sync, or contain a typo. A better version would look like this:
set testname "test foo"
gdb_test_multiple "print foo" $testname {
-re "expected output 1" {
pass $testname
}
-re "expected output 2" {
fail $testname
}
}
This is better, but its a bit of a drag having to create a new
variable each time.
After this patch you can now write this:
gdb_test_multiple "print foo" "test foo" {
-re "expected output 1" {
pass $gdb_test_name
}
-re "expected output 2" {
fail $gdb_test_name
}
}
The $gdb_test_name is setup by gdb_test_multiple, and cleaned up once
the test has completed. Nested calls to gdb_test_multiple are
supported, though $gdb_test_name will only ever contain the inner most
test message (which is probably what you want).
My only regret is that '$gdb_test_name' is so long, but I wanted
something that was unlikely to clash with any existing variable name,
or anything that a user is likely to want to use.
I've tested this on x86-64/GNU Linux and see no test regressions, and
I've converted one test script over to make use of this new technique
both as an example, and to ensure that the new facility doesn't get
broken. I have no plans to convert all tests over to this technique,
but I hope others will find this useful for writing tests in the
future.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_test_multiple): Add gdb_test_name mechanism.
* gdb.base/annota1.exp: Update to use gdb_test_name.
If gdb_test is used with fewer than five arguments, then the question_string
defaults to "^FOOBAR$":
...
if [llength $args]==5 {
set question_string [lindex $args 3]
set response_string [lindex $args 4]
} else {
set question_string "^FOOBAR$"
}
...
This can however match "FOOBAR", so perhaps "\$FOOBAR^" would have been a
better choice.
Eliminate the FOOBAR pattern from gdb_test by instead of defining a default
regexp, conditionally appending the regexp matching to a user_code variable.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test): Eliminate "^FOOBAR$" pattern.
In gdb.base/ui-redirect.exp, the "save breakpoint" command is used to write
the current breakpoints to a file, but the actual output is not verified.
Consequently, the test has regressed in that the "print 1" command associated
with a breakpoint on main is removed by a subsequent runto_main, which first
deletes all breakpoints:
...
(gdb) break main
Breakpoint 1 at 0x4004d7: file start.c, line 34.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
> PASS: gdb.base/ui-redirect.exp: commands
print 1
> PASS: gdb.base/ui-redirect.exp: print 1
end
(gdb) PASS: gdb.base/ui-redirect.exp: end
delete breakpoints
Delete all breakpoints? (y or n) y
...
and consequently the "save breakpoint" output is missing the breakpoint
command for main:
...
break main
- commands
- print 1
- end
break foo
break bar
...
Fix this by replacing "gdb_breakpoint main" with runto_main, and verifying the
"save breakpoints" output.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (cmp_file_string): New proc.
* gdb.base/ui-redirect.exp: Replace "gdb_breakpoint main" with
runto_main. Verify save breakpoints output.
The tcl proc skip_libstdcxx_probe_tests currently returns 0 if the probe tests
need to be skipped, while tcl interprets 0 as false rather than true, which is
confusing.
Fix this by making skip_libstdcxx_probe_tests return 1 if the probe tests need
to be skipped.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-26 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Return 1 if probe
* tests need to be skipped.
* gdb.cp/exceptprint.exp: Update call to skip_libstdcxx_probe_tests.
* gdb.mi/mi-catch-cpp-exceptions.exp: Update call to
mi_skip_libstdcxx_probe_tests.
Dejagnu produces an objdir like /c/, but GDB expects something like c:/.
So fix it up in lib/gdb.exp.
gdb/testsuite/ChangeLog:
2019-08-14 Christian Biesinger <cbiesinger@google.com>
* lib/gdb.exp: When running on a mingw target, replace
/x/ with x:/.
When running tests with check-read1, we run into some timeouts where the tests
are not easy to rewrite using gdb_test_sequence:
...
FAIL: gdb.base/help.exp: help data (timeout)
FAIL: gdb.base/help.exp: help files (timeout)
FAIL: gdb.base/help.exp: help internals (timeout)
FAIL: gdb.base/help.exp: help user-defined (timeout)
FAIL: gdb.base/help.exp: help breakpoint "b" abbreviation (timeout)
FAIL: gdb.base/help.exp: help breakpoint "br" abbreviation (timeout)
FAIL: gdb.base/help.exp: help breakpoint "bre" abbreviation (timeout)
FAIL: gdb.base/info-macros.exp: info macros 2 (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros 3 (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: next (timeout)
FAIL: gdb.base/info-macros.exp: info macros 7 (timeout)
FAIL: gdb.cp/nested-types.exp: ptype S10 (limit = -1) // parse failed (timeout)
FAIL: gdb.cp/nested-types.exp: set print type nested-type-limit 1 (timeout)
...
Fix these by increasing the timeout by a factor 10.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* lib/gdb.exp (with_read1_timeout_factor): New proc.
* gdb.base/help.exp: Use with_read1_timeout_factor.
* gdb.base/info-macros.exp: Same.
* gdb.cp/nested-types.exp: Same.
When running gdb.base/break-idempotent.exp with
--target_board=unix/-fno-PIE/-no-pie, we get:
...
nr of expected passes 140
...
The test-case is compiled once with nopie and once with pie, but in both cases
we end up with a non-PIE executable. The "-fno-PIE -no-pie" options specified
using the target_board are interpreted by dejagnu as multilib_flags, and end up
overriding the pie flags.
Fix this by checking in gdb_compile if the resulting exec is non-PIE despite of
a pie setting, and if so return an error:
...
Running gdb/testsuite/gdb.base/break-idempotent.exp ...
gdb compile failed, pie failed to generate PIE executable
=== gdb Summary ===
nr of expected passes 70
nr of untested testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (version_at_least): Factor out of ...
(tcl_version_at_least): ... here.
(gdb_compile): Fail if pie results in non-PIE executable.
(readelf_version, readelf_prints_pie): New proc.
(exec_is_pie): Return -1 if unknown.
In tcl_version_at_least we compare a minor against a major version number:
...
} elseif { $tcl_version_major == $major \
&& $tcl_version_major >= $minor } {
...
Fix this by using $tcl_version_minor in the comparison instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-05 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (tcl_version_at_least): Fix typo.
With gdb.base/structs.exp and check-read1 we get:
...
FAIL: gdb.base/structs.exp: p chartest (timeout)
...
Fix this by using gdb_test_sequence.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.base/structs.exp: Fix check-read1 timeout using
gdb_test_sequence.
* lib/gdb.exp (tcl_version_at_least, lrepeat): New proc.
When running gdb.base/dump.exp with --target_board=unix/-fPIE/-pie, we get:
...
Running gdb/testsuite/gdb.base/dump.exp ...
FAIL: gdb.base/dump.exp: dump array as value, intel hex
...
The FAIL happens because although the test specifies nopie, the exec is
in fact compiled as PIE. The "-fPIE -pie" options specified using the
target_board are interpreted by dejagnu as multilib_flags, and end up
overriding the nopie flags.
Fix this by checking in gdb_compile if the resulting exec is PIE despite of
a nopie setting, and if so return an error:
...
Running gdb/testsuite/gdb.base/dump.exp ...
gdb compile failed, nopie failed to prevent PIE executable
=== gdb Summary ===
nr of untested testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-30 Tom de Vries <tdevries@suse.de>
PR testsuite/24834
* lib/gdb.exp (gdb_compile): Fail if nopie results in PIE executable.
(exec_is_pie): New proc.
With check-read1 we get:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: check for stap probe in libstdc++
FAIL: gdb.mi/mi-nonstop.exp: probe for target remote
...
In both cases this is due to using gdb_test_multiple (which expects $gdb_prompt
by default) in combination with gdb using $gdb_mi_prompt, similar to the
problem fixed by commit d17725d72f "Don't expect gdb_prompt in
mi_skip_python_test".
Fix this by adding the $prompt_regexp argument to the gdb_test_multiple calls.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt, gdb_is_target_1):
Pass prompt_regexp parameter to gdb_test_multiple calls.
When running gdb.python/py-mi-events.exp with make check-read1, we get:
...
(gdb) ^M
python print ('test')^M
&"python print ('test')\n"^M
~"test\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: verify python support
^M
python print (sys.version_info[0])^M
&"python print (sys.version_info[0])\n"^M
~"2\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: check if python 3
^M
...
The FAILs happen as follows.
On one hand, skip_python_tests_prompt uses the prompt_regexp parameter for the
user_code argument of gdb_test_multiple:
...
proc skip_python_tests_prompt { prompt_regexp } {
global gdb_py_is_py3k
gdb_test_multiple "python print ('test')" "verify python support" {
-re "not supported.*$prompt_regexp" {
unsupported "Python support is disabled."
return 1
}
-re "$prompt_regexp" {}
}
gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
-re "3.*$prompt_regexp" {
set gdb_py_is_py3k 1
}
-re ".*$prompt_regexp" {
set gdb_py_is_py3k 0
}
}
...
On the other hand, gdb_test_multiple itself uses $gdb_prompt:
...
-re "\r\n$gdb_prompt $" {
if ![string match "" $message] then {
fail "$message"
}
set result 1
}
...
So when mi_skip_python_test calls skip_python_tests_prompt with prompt_regexp
set to $mi_gdb_prompt:
...
proc mi_skip_python_tests {} {
global mi_gdb_prompt
return [skip_python_tests_prompt "$mi_gdb_prompt$"]
}
...
and expect reads "(gdb) " and tries to match it (due to the READ1=1 setting),
the user_code regexps using $prompt_regexp (set to $mi_gdb_prompt) don't match,
but the $gdb_prompt regexp in gdb_test_multiple does match.
Fix this by adding a prompt_regexp parameter to gdb_test_multiple, and using the
parameter in skip_python_tests_prompt.
Tested gdb.python/py-mi-events.exp with make check READ1=1 x86_64-linux.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
PR gdb/24855
* lib/gdb.exp (gdb_test_multiple): Add prompt_regexp parameter.
(skip_python_tests_prompt): Add prompt_regexp argument to
gdb_test_multiple calls.
On a system without SDT probes in libstdc++, we run into:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
breakpoint in main (unknown output after running)
...
The test-case uses a regexp argument for the catch throw/rethrow/catch
command, which is only supported on systems with SDT probes in libstdc++.
Fix this by marking the portions of the test-case that use a regexp argument
as unsupported on a system without SDT probes.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-25 Tom de Vries <tdevries@suse.de>
PR testsuite/24830
* gdb.mi/mi-catch-cpp-exceptions.exp: Call
mi_skip_libstdcxx_probe_tests, and skip unsupported tests.
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Factor out of ...
(skip_libstdcxx_probe_tests): ... here.
* lib/mi-support.exp (mi_skip_libstdcxx_probe_tests): New proc.
Fix a silly bug in commit a26c8de0ee ("Fix early return in
foreach_with_prefix").
That patch made foreach_with_prefix always return after the first
iteration, making ~10k tests disappear from test runs...
This fixes it, and as penance, adds a testcase that exercises all
kinds of different returns possible (ok, error, return, break,
continue). I've written it with regular "foreach", and then switched
to foreach_with_prefix and made sure we get the same results. I put
the testcase in a new gdb.testsuite/ subdir, since this is exercising
the testsuite harness bits. We can move this elsewhere if people
prefer a different place, but I'm going ahead in order to unbreak the
testsuite ASAP.
gdb/testsuite/ChangeLog:
2019-07-04 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (foreach_with_prefix): Don't return early if
body returned ok(0), break(3) or continue(4).
* gdb.testsuite/foreach_with_prefix.exp: New file.
I noticed that an early return in a foreach_with_prefix block does not
cause the outer scope to return, like:
foreach_with_prefix var {"foo" "bar"} {
return
}
# Control continues here, but it should not.
The problem is that we're missing the usual "return -code" treatment.
This commit fixes it.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (foreach_with_prefix): Use "catch" and
"return -code".
TRANSCRIPT is superseeded by the .in, .cmd and .debug files, and
can be removed.
gdb/testsuite/ChangeLog
* README (Running the Testsuite): Change example.
(Testsuite Parameters): Remove TRANSCRIPT.
* lib/gdb.exp: Remove TRANSCRIPT check.
When spawning gdb or gdbserver create a .cmd file in the test output
directory containing the full command line, ensuring the current gdb
instance is appended to the files so that they can be quickly matched
to the corresponding gdb.in file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_spawn): Call gdb_write_cmd_file.
(gdb_write_cmd_file): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Call
gdbserver_write_cmd_file.
(gdbserver_write_cmd_file): New proedure.
When debugging testsuite failures, it can be awkward parsing gdb.log to
obtain all the commands run in order to manually re-run the test.
This patch adds the functionality to save all gdb commands to the file gdb.in
when the testsuite is run. The file is saved in the directory for the test and
if gdb is restarted then .1, .2, .3 etc is added to the filename.
Once a test has been run, the .in file can be used to re-run the test in the
following way:
gdb -x outputs/gdb.store/gdb.in outputs/gdb.store/store
The code works by intercepting send_gdb. I've added a TYPE to ensure that any
commands that would destroy the playback are kept from the log (for example the
Y from an answer to a y/n question).
Adds library function standard_output_file_with_gdb_instance to open a file
postfixed with count of the gdb instance. Ensure this count is reset when a new
.exp script is run.
I've re-run a random selection of .in files to check they do not error. Logs with
commands such as "attach <pid>" will not directly work when re-run.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_unload): Mark Y as an answer.
(delete_breakpoints): Likewise.
(gdb_run_cmd): Likewise.
(gdb_start_cmd): Likewise.
(gdb_starti_cmd): Likewise.
(gdb_internal_error_resync): Likewise.
(gdb_test_multiple): Likewise.
(gdb_reinitialize_dir): Likewise.
(default_gdb_exit): Likewise.
(gdb_file_cmd): Mark kill as optional.
(default_gdb_start): Call gdb_stdin_log_init.
(send_gdb): Call gdb_stdin_log_write.
(rerun_to_main): Mark Y as an answer.
(gdb_stdin_log_init): New function.
(gdb_stdin_log_write): Likewise.
Add both board option and environment variable which enables gdb
debug via a comma separated list and sends it to the file gdb.debug,
located in the output directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdb debug enabled in the following way:
make check GDB_DEBUG="infrun,target,remote"
A Test with multiple invocations of GDB will all append debug to the
same log file.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDB_DEBUG.
* README (Testsuite Parameters): Add GDB_DEBUG.
(gdb,debug): Add board setting.
* lib/gdb.exp (default_gdb_start): Start debugging.
(gdb_debug_enabled): New procedure.
(gdb_debug_init): Likewise.
In gdb.base/index-cache.exp, handle the case that binfile contains either a
.gdb_index or .debug_names index section.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (exec_has_index_section): New proc.
* gdb.base/index-cache.exp: Handle case that binfile contains an index
section.
When an Ada program is dynamically linked against libgnat, and when
one of the standard exceptions is used, the exception object may be
referenced by the main executable using a copy relocation.
In this situation, a "catch exception" for those exceptions will not
manage to stop. This happens because, under the hood, "catch
exception" creates an expression object that examines the object
addresses -- but in this case, the address will be incorrect.
This patch fixes the problem by arranging for these filter expressions
to examine all the relevant minimal symbols. This way, the object
from libgnat will be found as well.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_simple_minsyms): New function.
(create_excep_cond_exprs): Iterate over program spaces.
(ada_exception_catchpoint_cond_string): Examine all minimal
symbols for exception types.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* lib/ada.exp (find_ada_tool): New proc.
* lib/gdb.exp (gdb_compile_shlib): Allow .o files as inputs.
* gdb.ada/catch_ex_std.exp: New file.
* gdb.ada/catch_ex_std/foo.adb: New file.
* gdb.ada/catch_ex_std/some_package.adb: New file.
* gdb.ada/catch_ex_std/some_package.ads: New file.
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
Add both board option and environment variable which enables gdbserver
debug and sends it to the file gdbserver.debug, located in the output
directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdbserver debug enabled in the following way:
make check GDBSERVER_DEBUG=all
Disable tspeed.exp when debugging to prevent the log file filling
many gigabytes then timing out.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDBSERVER_DEBUG.
* README (Testsuite Parameters): Add GDBSERVER_DEBUG.
(gdbserver,debug): Add board setting.
* gdb.trace/tspeed.exp: Skip when debugging.
* lib/gdb.exp (gdbserver_debug_enabled): New procedure.
* lib/gdbserver-support.exp: Likewise
This changes the gdb test suite to omit -fno-stack-protector when
compiling Rust code. This makes Rust testing work again.
I think I saw this patch somewhere already, but I couldn't find it
again just now, so I'm checking this version in.
gdb/testsuite/ChangeLog
2019-04-24 Tom Tromey <tromey@adacore.com>
* lib/gdb.exp (gdb_compile): Don't add -fno-stack-protector for
Rust.
If an convenience function is defined in python (or guile), then
currently this will not work in Fortran, instead the user is given
this message:
(gdb) set language fortran
(gdb) p $myfunc (3)
Cannot perform substring on this type
Compare this to C:
(gdb) set language c
(gdb) p $myfunc (3)
$1 = 1
After this patch we see the same behaviour in both C and Fortran.
I've extended the test to check that all languages can call the
convenience functions - only Fortran was broken.
When calling convenience functions in Fortran we don't need to perform
the same value preparation (passing by pointer) that we would for
calling a native function - passing the real value is fine.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Handle internal functions
during Fortran function call handling.
gdb/testsuite/ChangeLog:
* gdb.python/py-function.exp: Check calling helper function from
all languages.
* lib/gdb.exp (gdb_supported_languages): New proc.
This commit fixes a regression in the testsuite itself, triggered by
errors being raised from within gdb_test_multiple, originally reported
by Pedro Franco de Carvalho's at
<https://sourceware.org/ml/gdb-patches/2019-03/msg00160.html>. Parts
of the commit message are based on his report.
This started happening due to a commit that was introduced recently,
and it can cause the testsuite to hang.
The commit that triggers this is:
fe1a5cad30
[gdb/testsuite] Log wait status on process no longer exists error
That commit introduces a new "eof" block in gdb_test_multiple. That
is not incorrect itself, but dejagnu's remote_expect is picking that
block as the "default" action when an error is raised from within the
commands inside a call to gdb_test_multiple:
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
#
proc remote_expect { board timeout args } {
I find that "feature" surprising, and I don't really know why it
exists, but this means that the eof section that remote_expect picks
as the error block can be executed even when there was no actual eof
and the GDB process is still running, so the wait introduced in the
commit that tries to get the exit status of GDB hangs forever, while
GDB itself waits for input.
This only happens when there are internal testsuite errors (not
testcase failures). This can be reproduced easily with a testcase
such as:
gdb_start
gdb_test_multiple "show version" "show version" {
-re ".*" {
error "forced error"
}
}
I think that working around this in GDB is useful so that the
testsuite doesn't hang in these cases.
Adding an empty "default" block at the end of the expect body in
gdb_test_multiple doesn't work, because dejagnu gives preference to
"eof" blocks:
if { $x eq "eof" } {
set save_next 1
} elseif { $x eq "default" || $x eq "timeout" } {
if { $error_sect eq "" } {
set save_next 1
}
}
And we do have "eof" blocks. So we need to make sure that the last
"eof" block is safe to use as the default error block. It's also
pedantically incorrect to print
"ERROR: Process no longer exists"
which is what we'd get if the last eof block we have was selected
(more below on this).
So this commit solves this by appending an "eof" with an empty
spawn_id list, so that it won't ever match.
Now, why is the first "eof" block selected today as the error block,
instead of the last one?
The reason is that remote_expect, while parsing the body to select the
default block to execute after an error, is affected by the comments
in the body (since they are also parsed).
If this comment in gdb_test_multiple
# patterns below apply to any spawn id specified.
is changed to
# The patterns below apply to any spawn id specified.
then the second eof block is selected and there is no hang.
Any comment at that same place with an even number of tokens also
works.
This is IMO a coincidence caused by how comments work in TCL.
Comments should only appear in places where a command can appear. And
here, remote_expect is parsing a list of options, not commands, so
it's not unreasonable to not parse comments, similarly to how this:
set a_list {
an_element
# another_element
}
results in a list with three elements, not one element.
The fact that comments with an even number of tokens work is just a
coincidence of how remote_expect's little state machine is
implemented.
I thought we could solve this by stripping out comment lines in
gdb_expect, but I didn't find an easy way to do that. Particularly, a
couple naive approaches I tried run into complications. For example,
we have gdb_test calls with regular expressions that include sequences
like "\r\n#", and by the time we get to gdb_expect, the \r\n have
already been expanded to a real newline, so just splitting the whole
body at newline boundaries, looking for lines that start with #
results in incorrectly stripping out half of the gdb_text regexp. I
think it's better (at least in this commit), to move the comments out
of the list, because it's much simpler and risk free.
gdb/testsuite/ChangeLog:
2019-03-25 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Split appends to $code and
move comments outside list. Append '-i "" eof' section.
Recent versions of Ubuntu and Debian default GCC to enable pie.
In dump.exp, pie will causes addresses to be out of range for IHEX.
In break-interp.exp, pie is explicitly set for some tests and assumed
to be disabled for the remainder.
Ensure pie is disabled for these tests when required.
In addition, add a pie option to gdb_compile to match the nopie option
and simplify use.
gdb/testsuite/ChangeLog:
* README: Add pie options.
* gdb.base/break-interp.exp: Ensure pie is disabled.
* gdb.base/dump.exp: Likewise.
* lib/gdb.exp (gdb_compile): Add pie option.
get_compiler_info switches to a new log file before checking the compiler
to ensure the checks are not logged. Afterwards it restores back to using
the original log file. However, the logfile uses a relative path name -
if the current test has changed the current directory then all further
output for the test will be lost. This can confuse the code that collates
the main gdb.log file at the end of a FORCE_PARALLEL run.
fullpath-expand.exp calls gdb_compile after changing the current directory.
The "Ensure stack protection is off for GCC" patch added a call to
get_compiler_info from inside of gdb_compile, causing log file collection
to break for FORCE_PARALLEL runs.
The ideal solution would be to ensure the log file is always created using
an absolute path name. However, this is set at multiple points in
Makefile.in and in some instances just relies on dejagnu common code to set
the log file directory to "."
The simpler and safer solution is to override the builtin cd function. The
new function checks the current log file and if the path is relative, then
it resets the logging using an absolute path. Finally it calls the builtin
cd. This ensures get_compiler_info (and any other code) can correctly
backup and restore the current log file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (builtin_cd): rename of cd.
(cd): Override builtin.
When creating a pty to spawn a subprocess (such as gdb), Expect
copies the settings of its own controlling terminal, including the
number of rows and columns. If you "make check" on a terminal with just
a few rows (e.g. 4), GDB will paginate before reaching the initial
prompt. In default_gdb_start, used by most tests, this is already
handled: if we see the pagination prompt, we sent \n to continue.
Philippe reported that gdb.base/corefile.exp didn't work in terminals
with just a few rows. This test spawns GDB by hand, because it needs to
check things before the initial prompt, which it couldn't do if it used
default_gdb_start.
In this case I think it's not safe to use the same technique as in
default_gdb_start. Even if we could send a \n if we see a pagination
prompt, we match some multiline regexes in there. So if a pagination
slips in there, it might make the regexes not match and fail the test.
It's also not possible to use -ex "set height 0" or -iex "set height 0",
it is handled after the introduction text is shown.
The simplest way I found to avoid showing the pagination completely is
to set stty_init (documented in expect's man page) to initialize gdb's
pty with a fixed number of rows.
And actually, if we set stty_init in gdb_init, it works nicely as a
general solution applicable to all tests. We can therefore remove the
solution introduced in e882ef3cfc ("testsuite: expect possible
pagination when starting gdb") where we matched the pagination prompt
during startup.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_start): Don't match pagination
prompt.
(gdb_init): Set stty_init.
Using -fstack-protector-strong will cause GDB to break on the wrong line
when placing a breakpoint on a function. This is due to inadequate dwarf
line numbering, and is being tracked by the GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
GCC (and Clang) provided by Debian/Ubuntu default to stack protector
being enabled.
Ensure that when running the GDB testsuite, stack protector is always
turned off for GCC 4.1.0 (when stack protector was added) and above.
Ensure that this does not cause infinite recursion due to
test_compiler_info having to compile a file itself.
Add a test to explicitly test breakpoints with various levels of stack
protection on both GCC and Clang, with xfail for the known errors.
Restore change in ovldbreak.exp which worked around the issue.
gdb/testsuite/ChangeLog:
2019-01-18 Alan Hayward <alan.hayward@arm.com>
* gdb.base/stack-protector.c: New test.
* gdb.base/stack-protector.exp: New file.
* gdb.cp/ovldbreak.exp: Only allow a single break line.
* lib/gdb.exp (get_compiler_info): Use getting_compiler_info
option.
(gdb_compile): Remove stack protector for GCC and prevent
recursion.
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
This changes the gdb test suite to set TERM to "dumb" by default.
This setting disables terminal styling, so that the existing tests do
not need to be updated.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_init): Set the TERM environment variable to
"dumb".
* gdb.base/readline.exp (operate_and_get_next): Save and restore
the TERM environment variable.
Various tests use test code written in i386 / x86_64 assembly that cannot
be used to create PIE executables. Therefore compilation of test programs
failed on systems where the compiler default is to create PIE executable.
The solution is to use -no-pie linker flag, however, such flag may not
(is not) supported by all compilers GDB needs to support (e.g. gcc 4.8).
To handle this, introduce a new flag to gdb_compile - nopie - which
inserts -no-pie linker flag where supported and is no-op where it is
not. By default, -no-pie flag is inserted since most modern compiler do
support it.
The get_valueof outputs the value it has read as part of the test name. This
causes test names to vary from run to run, and adds some noise when diffing
test results. e.g.:
-PASS: gdb.guile/scm-ports.exp: buffered: get valueof "$sp" (140737488343920)
+PASS: gdb.guile/scm-ports.exp: buffered: get valueof "$sp" (140737488343968)
-PASS: gdb.guile/scm-ports.exp: unbuffered: get valueof "$sp" (140737488343920)
+PASS: gdb.guile/scm-ports.exp: unbuffered: get valueof "$sp" (140737488343968)
This patch removes that, since it's probably not very useful.
Tested on x86_64-linux.
2018-10-31 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (get_valueof): Don't output read value in test name.
Proc gdb_test_multiple can run into a process no longer exists error, but when
that happens it shows no details about the process:
...
ERROR: Process no longer exists
...
Fix this by showing the wait status of the process in the log:
...
ERROR: GDB process no longer exists
GDB process exited with wait status 8106 exp8 0 0 CHILDKILLED SIGSEGV \
{segmentation violation}
...
In order to run the wait commmand we need an explicit pid, so we can't use
any_spawn_id, and duplicate the "-i any_spawn_id eof" pattern for gdb_spawn_id,
and add the wait status logging there.
Build and tested on x86_64-linux.
2018-10-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Log wait status on process no
longer exists error.
When calling gdb_start_cmd, it's the caller's responsibility to wait for gdb
to return to the prompt. In target_supports_scheduler_locking, that's not the
case, and consequently, target_supports_scheduler_locking fails spuriously.
Fix by using runto_main instead.
Build and reg-tested on x86_64-linux.
2018-10-09 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd
with runto_main.
This patch is another attempt to fix PR cli/19551. Unlike my previous
attempt, it doesn't print progress. Instead, it just changes some
messages and adds newlines to make the output a bit nicer.
It also removes the "done." text that was previously emitted. The
idea here is that it is obvious when gdb is done reading debug info,
as it starts then doing something else; and that while this message
did not provide much benefit to users, it did make it harder to make
the output clean.
After this change the output from "./gdb -iex 'set complaint 1' -nx ./gdb"
reads:
Reading symbols from ./gdb...
.debug_ranges entry has start address of zero [in module /home/tromey/gdb/build/gdb/gdb]
DW_AT_low_pc 0x0 is zero for DIE at 0x17116c1 [in module /home/tromey/gdb/build/gdb/gdb]
.debug_line address at offset 0xa22f5 is 0 [in module /home/tromey/gdb/build/gdb/gdb]
During symbol reading, unsupported tag: 'DW_TAG_unspecified_type'.
During symbol reading, const value length mismatch for 'std::ratio<1, 1000000000>::num', got 8, expected 0.
gdb/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* symfile.c (symbol_file_add_with_addrs): Update output.
* psymtab.c (require_partial_symbols): Update output.
gdb/testsuite/ChangeLog
2018-10-04 Tom Tromey <tom@tromey.com>
PR cli/19551:
* lib/mi-support.exp (mi_gdb_file_cmd): Update.
* lib/gdb.exp (gdb_file_cmd): Update.
* gdb.stabs/weird.exp (print_weird_var): Update.
* gdb.server/solib-list.exp: Update.
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Update.
* gdb.mi/mi-cli.exp: Update.
* gdb.linespec/linespec.exp: Update.
* gdb.dwarf2/dw2-stack-boundary.exp: Update.
* gdb.dwarf2/dw2-objfile-overlap.exp: Update.
* gdb.cp/cp-relocate.exp: Update.
* gdb.base/sym-file.exp: Update.
* gdb.base/relocate.exp: Update.
* gdb.base/readnever.exp: Update.
* gdb.base/print-symbol-loading.exp (test_load_core): Update.
* gdb.base/kill-detach-inferiors-cmd.exp: Update.
* gdb.base/dbx.exp (gdb_file_cmd): Update.
* gdb.base/code_elim.exp: Update.
* gdb.base/break-unload-file.exp (test_break): Update.
* gdb.base/break-interp.exp (test_attach_gdb): Update.
* gdb.base/break-idempotent.exp (force_breakpoint_re_set):
Update.
* gdb.base/attach.exp (do_attach_tests): Update.
* gdb.base/sepdebug.exp: Update.
* gdb.python/py-section-script.exp: Update.
Joel Brobecker
Kevin Buettner
Andrew Burgess
Tom de Vries
Christian Biesinger
Pedro Alves
Philippe Waroquiers
Alan Hayward
Tom Tromey
Simon Marchi
Tom Tromey
Jan Vrany
Sandra Loosemore