| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Many of the test scripts create variables in the global namespace,
these variables will then be present for the following test scripts.
In most cases this is harmless, but in some cases this can cause
problems.
For example, if a variable is created as an array in one script, but
then assigned as a scalar in a different script, this will cause a TCL
error.
The solution proposed in this patch is to have the GDB test harness
record a list of all known global variables at the point just before
we source the test script. Then, after the test script has run, we
again iterate over all global variables. Any variable that was not in
the original list is deleted, unless it was marked as a persistent global
variable using gdb_persistent_global.
The assumption here is that no test script should need to create a
global variable that will outlive the lifetime of the test script
itself. With this patch in place all tests currently seem to pass, so
the assumption seems to hold.
gdb/testsuite/ChangeLog:
2020-06-12 Andrew Burgess <andrew.burgess@embecosm.com>
Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_known_globals, gdb_persistent_globals): New global.
(gdb_persistent_global, gdb_persistent_global_no_decl): New proc.
(gdb_setup_known_globals): New proc.
(gdb_cleanup_globals): New proc.
* lib/gdb.exp (load_lib): New override proc.
(gdb_stdin_log_init): Set var in_file as persistent global.
* lib/pascal.exp (gdb_stdin_log_init): Set vars
pascal_compiler_is_gpc, pascal_compiler_is_fpc, gpc_compiler and
fpc_compiler as persistent global.
|
|
In lib/tuiterm.exp the builtin spawn is overridden by a tui-specific version.
After running the first test-case that imports tuiterm.exp, the override
remains active, so it can cause trouble in subsequent test-cases, even if they
do not import tuiterm.exp. See f.i. commit c8d4f6dfd9 "[gdb/testsuite] Fix
spawn in tuiterm.exp".
Fix this by:
- adding a variable gdb_finish_hooks which is a list of procs to run during
gdb_finish
- adding a proc tuiterm_env that is used in test-cases instead of
"load_lib tuiterm.exp".
- letting tuiterm_env:
- install the tui-specific spawn version, and
- use the gdb_finish_hooks to schedule restoring the builtin spawn
version.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-12 Tom de Vries <tdevries@suse.de>
* lib/tuiterm.exp (spawn): Rename to ...
(tui_spawn): ... this.
(toplevel): Move rename of spawn ...
(gdb_init_tuiterm): ... here. New proc.
(gdb_finish_tuiterm): New proc.
* lib/gdb.exp (gdb_finish_hooks): New global var.
(gdb_finish): Handle gdb_finish_hooks.
(tuiterm_env): New proc.
* gdb.python/tui-window.exp: Replace load_lib tuiterm.exp with
tuiterm_env.
* gdb.tui/basic.exp: Same.
* gdb.tui/corefile-run.exp: Same.
* gdb.tui/empty.exp: Same.
* gdb.tui/list-before.exp: Same.
* gdb.tui/list.exp: Same.
* gdb.tui/main.exp: Same.
* gdb.tui/new-layout.exp: Same.
* gdb.tui/regs.exp: Same.
* gdb.tui/resize.exp: Same.
* gdb.tui/tui-layout-asm-short-prog.exp: Same.
* gdb.tui/tui-layout-asm.exp: Same.
* gdb.tui/tui-missing-src.exp: Same.
* gdb.tui/winheight.exp: Same.
|
|
Say we add a call to foobar at the end of a test-case, and run the
test-suite. We'll run into a dejagnu error:
...
ERROR: (DejaGnu) proc "foobar" does not exist.
...
and the test-suite run is aborted.
It's reasonable that the test-case is aborted, but it's not reasonable that
the testsuite run is aborted.
Problems in one test-case should not leak into other test-cases, and they
generally don't. The exception is the "invalid command name" problem due to
an override of ::unknown in dejagnu's framework.exp.
Fix this by reverting dejagnu's ::unknown override for the duration of each
test-case, using the gdb_init/gdb_finish hooks.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-12 Tom de Vries <tdevries@suse.de>
PR testsuite/26110
* lib/gdb.exp (gdb_init): Revert dejagnu's override of ::unknown.
(gdb_finish): Reinstall dejagnu's override of ::unknown.
|
|
Test-case gdb.base/dbx.exp overrides:
- the GDBFLAGS variable
- the gdb_file_cmd proc
There's code at the end of the test-case to restore both, but that's not
guaranteed to be executed.
Fix this by:
- using save_vars to restore GDBFLAGS
- using a new proc with_override to restore gdb_file_cmd
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-11 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (with_override): New proc, factored out of ...
* gdb.base/dbx.exp: ... here. Use with_override and save_vars.
|
|
In gdb_file_cmd, perror is called with error message strings using $arg and
$GDB, both of which contain path names, which makes comparison of gdb.sum
files more difficult.
Fix this by using:
- [file tail $arg] instead of $arg
- GDB instead of $GDB.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-04 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_file_cmd): Avoid path names in error messages.
|
|
Consider a gdb_load patch to call the gdb_file_cmd twice:
...
proc gdb_load { arg } {
if { $arg != "" } {
+ set res [gdb_file_cmd $arg]
+ if { $res != 0 } {
+ return $res
+ }
return [gdb_file_cmd $arg]
}
return 0
}
...
When running test-case gdb.base/index-cache.exp, we run into:
...
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache, other program \
already loaded (timeout).
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: check index-cache \
stats (GDB internal error)
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache, other program \
already loaded (timeout).
...
The first timeout in more detail:
...
(gdb) file outputs/gdb.base/index-cache/index-cache^M
Load new symbol table from "index-cache"? (y or n) y^M
Reading symbols from index-cache...^M
src/gdb/dwarf2/read.c:2540: internal-error: \
void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, \
const gdb_byte*, offset_type): \
Assertion `per_bfd->all_comp_units.empty ()' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) ERROR: Couldn't load index-cache, \
other program already loaded (timeout).
...
Proc gdb_file_cmd has a gdb_expect handling the result of the file command,
and if the result is a "Load new symbol table from index-cache? (y or n) "
prompt, it sends a "y" and enters in a nested gdb_expect to handle the
result.
The first gdb_expect contains code to handle "A problem internal to GDB has
been detected", but the second one doesn't, which causes the timeout.
Fix this by removing the nested gdb_expect, and using exp_continue instead,
such that we have instead:
...
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache -- with new \
symbol table into gdb (GDB internal error).
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache -- with new \
symbol table into gdb (GDB internal error).
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-04 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_file_cmd): Replace incomplete gdb_expect by
exp_continue.
|
|
When building gdb using this patch:
...
static void
file_command (const char *arg, int from_tty)
{
+ gdb_assert (0);
...
and running the testsuite, we run into:
...
Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ...
PASS: gdb.ada/O2_float_param.exp: compilation foo.adb
FAIL: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \
(GDB internal error)
PATH: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \
(GDB internal error)
FAIL: gdb.ada/O2_float_param.exp: frame
...
The FAIL detecting the GDB internal error is generated by this clause in
gdb_file_cmd:
...
-re "A problem internal to GDB has been detected" {
fail "($arg) (GDB internal error)"
gdb_internal_error_resync
return -1
}
...
The fail message has no text outside parenthesis, and could be considered
empty. Also, it's the only clause in the gdb_expect that uses fail, the
rest uses perror.
Fix this by replacing the fail by perror, such that we have:
...
Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ...
PASS: gdb.ada/O2_float_param.exp: compilation foo.adb
ERROR: Couldn't load outputs/gdb.ada/O2_float_param/foo into \
gdb (GDB internal error).
UNRESOLVED: gdb.ada/O2_float_param.exp: frame
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-04 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_file_cmd): Use perror instead of fail.
|
|
Add a test for verifying different methods of passing arguments to the
inferior: the start, starti and run commands, as well as `set args`.
All these methods work naturally when using the unix or
native-extended-gdbserver target boards. Since those are non-stub
boards, GDB runs new inferiors and therefore pass arguments to them.
With target boards where GDB connects to a stub, for example with
native-gdbserver, they don't really make sense. The inferior process is
already started when GDB connects.
However, the "run" method is still tested with stub targets, because the
gdb_run_cmd procedure is adapted for stub targets. Instead of issuing
the `run` command, it spawns whatever program is supposed to bring up
the stub (gdbserver, for example) using gdb_reload and makes GDB connect
to it. So this allows us to exercise argument passing through the
gdbserver command line, when testing with the native-gdbserver board.
Note that there is already a gdb.base/args.exp, but this tests
specifically the --args switch of GDB. Perhaps it could be integrated
in this new test, as a new "method".
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_run_cmd): Return success or failure.
* gdb.base/inferior-args.exp: New file.
* gdb.base/inferior-args.c: New file.
Change-Id: Ib61ea6220a47f9f67aed2960dcacd240cb57af70
|
|
This patch makes it possible to run tests requiring passing arguments to
the inferior with the native-gdbserver board. The end goal is to write
a test that verifies passing arguments to the inferior works, and to
have that test exercise inferior arguments passed on the gdbserver
command line, when using the native-gdbserver target board (in addition
to the other boards). This is done in the next patch.
With the native-gdbserver target board, gdbserver is started in
gdb_reload (implemented in config/gdbserver.exp), called in gdb_run_cmd.
gdb_run_cmd already supposedly accepts inferior arguments (although that
feature does not seem to be used anywhere), which it passes to the `run`
command, for non-stub target boards. I've changed gdb_run_cmd so that
it forwards these arguments to gdb_reload as well. gdb_reload passes
them to gdbserver_run, and they eventually make their way to the
gdbserver command line.
gdb_run_cmd currently accepts `args` (the varargs of tcl), which means
it receives inferior arguments as a list. This won't work with
arguments with spaces, because they will end up being formatted with
curly braces like this:
% set args [list hello "with spaces" world]
hello {with spaces} world
% puts "run $args"
run hello {with spaces} world
I've changed it to accept a single string that is passed to `run` and
gdb_reload. I've done the same change in gdb_start_cmd and
gdb_starti_cmd, although these two are not used with native-gdbserver.
I've changed all gdb_reload implementations in the tree to accept a new
inferior_args argument, although most of them don't do anything with it
(and don't need to). People maintaining target boards out of tree will
need to do the same.
I found two tests to adjust to avoid adding new failures or errors.
These tests needed new [use_gdb_stub] checks, because they rely on
having GDB run new processes. These are guarded by a [target_info
exists noargs], which made them get skipped on native-gdbserver. But
now that the native-gdbserver board supports args, this is no longer
enough.
Note that with this change, noargs and use_gdb_stub are orthogonal. It
took me a moment to grasp this, so I thought I would spell out the
different possible situations:
- !noargs and !use_gdb_stub: inferior process started by gdb, can pass
args
- noargs and !use_gdb_stub: inferior process started by gdb (perhaps
through extended-remote protocol, the simulator, some other target),
but that target doesn't support inferior arguments
- noargs and use_gdb_stub: inferior process started by some other
program to which GDB connects using the remote protocol, that program
does not support passing args to the inferior process
- !noargs and use_gdb_stub: inferior process started by some other
program to which GDB connects u sing the remote protocol, that program
supports passing args to the inferior process
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_run_cmd): Change argument from args to
inferior_args. Pass it to gdb_reload.
(gdb_start_cmd, gdb_starti_cmd): Change argument from args to
inferior_args.
(gdb_reload): Add inferior_args argument.
* config/gdbserver.exp (gdb_reload): Add inferior_args argument,
pass it to gdbserver_run.
* boards/native-gdbserver.exp: Do not set noargs.
* boards/native-extended-gdbserver.exp (gdb_reload): Add
inferior_args argument.
* boards/stdio-gdbserver-base.exp (gdb_reload): Likewise.
* gdb.base/a2-run.exp: Check for use_gdb_stub.
* gdb.base/args.exp: Likewise.
Change-Id: Ibda027c71867157852f34700342ab31edf39e4d8
|
|
Add comment to exec_is_pie explaining why readelf -d output is not used.
gdb/testsuite/ChangeLog:
2020-05-25 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (exec_is_pie): Add comment.
|
|
In commit 1b59ca1cf1 "[gdb/testsuite] Fix tcl error in jit-elf-helpers.exp", I
introduced a variable f in compile_and_download_n_jit_so, to be used in the
untested message, but actually variable binfile was used instead:
...
+ set f [file tail $binfile]
+ untested "failed to compile shared library $binfile"
...
Fix this by using $f in the untested message.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-25 Tom de Vries <tdevries@suse.de>
* lib/jit-elf-helpers.exp (compile_and_download_n_jit_so): Use $f
instead of $binfile in the untested message.
|
|
When running test-case gdb.base/break-interp.exp with target board gold, we
run into:
...
gdb compile failed, pie failed to generate PIE executable
...
The problem is that the proc exec_is_pie uses the PIE flag in the readelf -d
output, which doesn't seem to be set by the gold linker.
Instead, use the "Type" field in the readelf -h output.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-25 Tom de Vries <tdevries@suse.de>
PR testsuite/26031
* lib/gdb.exp (exec_is_pie): Test readelf -h output.
|
|
This reverts commit eca1f90cf47a2edc1a1cd22e12c6c0f3b900654e. Several
changes were requested, and it seemed simplest to revert it.
gdb/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
Revert commit eca1f90c:
* NEWS: Remove entry for completion styling.
* completer.c (_rl_completion_prefix_display_length): Move
declaration later.
(gdb_fnprint): Revert.
(gdb_display_match_list_1): Likewise.
* cli/cli-style.c (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Remove.
(_initialize_cli_style): Revert.
* cli/cli-style.h (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Don't
declare.
gdb/doc/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Output Styling): Don't mention completion styling.
(Editing): Don't mention readline completion styling.
gdb/testsuite/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Remove completion styling test.
* lib/gdb-utils.exp (style): Remove completion styles.
|
|
Readline has a styling feature for completion -- if it is enabled, the
common prefix of completions will be displayed in a different style.
This doesn't work in gdb, because gdb implements its own completer.
This patch implements the feature. However, it doesn't directly use
the Readline feature, because gdb can do a bit better: it can let the
user control the styling using the existing mechanisms.
This version incorporates an Emacs idea, via Eli: style the prefix,
the "difference character", and the suffix differently.
gdb/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for completion styling.
* completer.c (_rl_completion_prefix_display_length): Move
declaration earlier.
(gdb_fnprint): Use completion_style.
(gdb_display_match_list_1): Likewise.
* cli/cli-style.c (completion_prefix_style)
(completion_difference_style, completion_suffix_style): New
globals.
(_initialize_cli_style): Register new globals.
* cli/cli-style.h (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Declare.
gdb/doc/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Output Styling): Mention completion styling.
(Editing): Mention readline completion styling.
gdb/testsuite/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add completion styling test.
* lib/gdb-utils.exp (style): Add completion styles.
|
|
Revert this commit:
commit 843f4d93576eef02139f7b1b3fa1cea7b0f286f1
Date: Tue May 12 17:38:17 2020 +0100
gdb/testsuite: Disable path and duplicate checks when parallel testing
Now that this commit has landed:
commit c959562d9ba0b2eaf240c601b2c2fd49c42c1f2f
Date: Fri May 15 11:23:59 2020 +0100
contrib: Update dg-extract-results.* from gcc
We can now make use of the mechanism for detecting paths in test names
and duplicate test names, even when we run tests in parallel.
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp: Remove code that prevents this file
loading when tests are run in parallel.
|
|
This commit disables the recently added checking for paths in test
names, and for duplicate test names, when the gdb tests are run in
parallel.
When running the gdb tests in parallel the extra result count lines
produced cause the dg-extract-results scripts to exit with an error.
The patches for the dg-extract-results scripts have been posted to the
gcc-patches mailing list here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545562.html
Once they are merged there then these changes can be merged over to
binutils-gdb, and this commit can be reverted.
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp: Disable when testing is being run in
parallel.
|
|
When running test-case jit-elf.exp with target board cc-with-gdb-index, I run
into:
...
gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/jit-elf.exp.
ERROR: can't read "main_basename": no such variable
while executing
"untested "failed to compile ${main_basename}.c""
(procedure "compile_jit_main" line 7)
...
The problem is in compile_jit_main in lib/jit-elf-helpers.exp, where we try to
emit an untested message using global variable main_basename.c.
Fixing this by declaring the variable global results in duplicate test-names,
because the same source file is compiled more than once.
Instead, fix this by using the result name in the untested message.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* lib/jit-elf-helpers.exp: Don't use undefined variables in untested
messages.
|
|
Replaces previous approach with patching resulting ELF binary after
loading - now that each test iteration works on a separately compiled
binary it is not necessary anymore.
Tests are still being ran without debug info to preserve original test
functionality but this change opens up the possibility to enable debug
info if needed too.
gdb/testsuite/ChangeLog:
2020-03-27 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -DFUNCTION_NAME macro
definition when compiling jit-elf-solib.co.
* gdb.base/jit-elf-main.c: Stop patching jit function name.
* gdb.base/jit-elf-solib.c: Use FUNCTION_NAME macro value as a
function name.
|
|
Removes the need to manually relocate loaded ELF binary by using a fixed
constant as both mmap base address and as a requested first segment
address supplied to the linker.
In future will enable JIT tests with a valid DWARF debug info. Current
tests still need to compile without a debug info though, because they do
a function name modification.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -Ttext-segment linker flag and
define LOAD_ADDRESS/LOAD_INCREMENT macros for the compiled binaries.
* gdb.base/jit-elf-main.c: Use LOAD_ADDRESS/LOAD_INCREMENT to
calculate the mmap address.
|
|
New utility library to be used by jit-elf tests responsible for
compiling binary artifacts. In the next commit the compilation process
will become more complicated because of extra mandatory flag - keeping
it in one place will make tests less fragile.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: New file.
* gdb.base/jit-elf.exp: Updated to use jit-elf-helpers.exp.
* gdb.base/jit-elf-so.exp: Updated to use jit-elf-helpers.exp.
|
|
Building on the previous commit, this patch detects when two tests
have the same test name and causes Dejagnu to print a new result type
'# of duplicate test names' in the result summary. A line starting
with 'DUPLICATE: ' is also added to the gdb.sum and gdb.log files.
The DUPLICATE markers will be printed the second time a duplicate test
name is seen, and every time after that. So you might see:
PASS: gdb.base/sometest.exp: foo
PASS: gdb.base/sometest.exp: bar
PASS: gdb.base/sometest.exp: foo
DUPLICATE: gdb.base/sometest.exp: foo
PASS: gdb.base/sometest.exp: baz
PASS: gdb.base/sometest.exp: foo
DUPLICATE: gdb.base/sometest.exp: foo
However, the results will report a duplicate count of 1, indicating
that just one test name (foo) was duplicated.
Currently if the tests are run in parallel mode the new result type is
not merged into the combined summary file so users will need to run in
non-parallel mode to check this result. Similarly, the 'DUPLICATE: '
markers will not be merged into the final gdb.sum file. A later
commit will fix this.
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp (all_test_names): New module variable.
(counts): Add 'duplicates' field.
(_check_duplicates): New procedure.
(check): Also check for duplicates.
(do_log_summary): Print duplicates count.
(do_reset_vars): Reset counter for duplicate test names, and
discard all know test names.
|
|
A new library is introduced that hooks into the core of Dejagnu and
detects when a test's name includes either the source or build paths.
If any offending test names are detected then Dejagnu will print a
new result type, '# of paths in test names'. Users should treat this
result type just like other bad results types, and aim not to increase
this number.
As well as displaying the total number of offending tests as part of
the final results, a new marker is included in both the gdb.log and
gdb.sum files, this marker starts with 'PATH: ', so an offending test
would be expected to appear like this:
PASS: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe
PATH: gdb.base/sometest.exp: Loaded /path/to/build/testsuite/foo.exe
This should make it easier to track down offending tests.
Currently for a local run on my machine, I don't see any offending
test names, but it is possible that different targets, or different
configurations, might currently be breaking the no paths rule.
In order to get this working I have needed to wrap two core Dejagnu
functions, log_summary, and reset_vars. Relying on core functions
that are not part of any API is always going to be risky, given the
relatively slow rate of Dejagnu change this is probably OK for now,
and we can possibly upstream some changes to Dejagnu that would allow
this functionality to be supported in a more official way later on.
Currently if the tests are run in parallel mode the new result type is
not merged into the combined summary file so users will need to run in
non-parallel mode to check this result. Similarly, the 'PATH: '
markers will not be merged into the combined summary file. A later
commit will fix this.
gdb/testsuite/ChangeLog:
* lib/gdb.exp: Include check-test-names.exp library.
* lib/check-test-names.exp: New file.
|
|
Name of fortran main function for Flang compiler is MAIN_ while
for gfortran it is MAIN__ . In test cases MAIN__ is hardcoded for
the purpose of inserting breakpoint.
New proc is added to detect main function name depending on the
compiler used.
Fortran specific version of runto_main named fortran_runto_main
is added.
This commit adds support for Flang main function, there should be
no change for gfortran.
gdb/testsuite/ChangeLog
* lib/fortran.exp (fortran_main): New Proc, handle flang MAIN_,
(fortran_runto_main): New Proc, fortran version of runto_main.
* gdb.fortran/array-bounds-high.exp: Handle flang MAIN_.
* gdb.fortran/array-bounds.exp: Likewise.
* gdb.fortran/array-slices.exp: Likewise.
* gdb.fortran/block-data.exp: Likewise.
* gdb.fortran/charset.exp: Likewise.
* gdb.fortran/common-block.exp: Likewise.
* gdb.fortran/complex.exp: Likewise.
* gdb.fortran/derived-type-function.exp: Likewise.
* gdb.fortran/derived-type.exp: Likewise.
* gdb.fortran/info-modules.exp: Likewise.
* gdb.fortran/info-types.exp: Likewise.
* gdb.fortran/intrinsics.exp: Likewise.
* gdb.fortran/library-module.exp: Likewise.
* gdb.fortran/logical.exp: Likewise.
* gdb.fortran/max-depth.exp: Likewise.
* gdb.fortran/module.exp: Likewise.
* gdb.fortran/multi-dim.exp: Likewise.
* gdb.fortran/nested-funcs.exp: Likewise.
* gdb.fortran/print-formatted.exp: Likewise.
* gdb.fortran/print_type.exp: Likewise.
* gdb.fortran/printing-types.exp: Likewise.
* gdb.fortran/ptr-indentation.exp: Likewise.
* gdb.fortran/ptype-on-functions.exp: Likewise.
* gdb.fortran/subarray.exp: Likewise.
* gdb.fortran/vla-alloc-assoc.exp: Likewise.
* gdb.fortran/vla-datatypes.exp: Likewise.
* gdb.fortran/vla-history.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-ptype-sub.exp: Likewise.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-sizeof.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value-sub-arbitrary.exp: Likewise.
* gdb.fortran/vla-value-sub-finish.exp: Likewise.
* gdb.fortran/vla-value-sub.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
* gdb.fortran/whatis_type.exp: Likewise.
* gdb.mi/mi-var-child-f.exp: Likewise.
|
|
v2:
- test: build full executable instead of object
- test: add and use supports_fcf_protection
- test: use gdb_test_multiple's -wrap option
- test: don't execute gdb_assert if failed to get breakpoint address
Some GCCs now enable -fcf-protection by default. This is the case, for
example, with GCC 9.3.0 on Ubuntu 20.04. Enabling it causes the
`endbr64` instruction to be inserted at the beginning of all functions
and that breaks GDB's prologue analysis.
I noticed this because it gives many failures in gdb.base/break.exp.
But let's take this dummy program and put a breakpoint on main:
int main(void)
{
return 0;
}
Without -fcf-protection, the breakpoint is correctly put after the prologue:
$ gcc test.c -g3 -O0 -fcf-protection=none
$ ./gdb -q -nx --data-directory=data-directory a.out
Reading symbols from a.out...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000001129 <+0>: push %rbp
0x000000000000112a <+1>: mov %rsp,%rbp
0x000000000000112d <+4>: mov $0x0,%eax
0x0000000000001132 <+9>: pop %rbp
0x0000000000001133 <+10>: retq
End of assembler dump.
(gdb) b main
Breakpoint 1 at 0x112d: file test.c, line 3.
With -fcf-protection, the breakpoint is incorrectly put on the first
byte of the function:
$ gcc test.c -g3 -O0 -fcf-protection=full
$ ./gdb -q -nx --data-directory=data-directory a.out
Reading symbols from a.out...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000001129 <+0>: endbr64
0x000000000000112d <+4>: push %rbp
0x000000000000112e <+5>: mov %rsp,%rbp
0x0000000000001131 <+8>: mov $0x0,%eax
0x0000000000001136 <+13>: pop %rbp
0x0000000000001137 <+14>: retq
End of assembler dump.
(gdb) b main
Breakpoint 1 at 0x1129: file test.c, line 2.
Stepping in amd64_skip_prologue, we can see that the prologue analysis,
for GCC-compiled programs, is done in amd64_analyze_prologue by decoding
the instructions and looking for typical patterns. This patch changes
the analysis to check for a prologue starting with the `endbr64`
instruction, and skip it if it's there.
gdb/ChangeLog:
* amd64-tdep.c (amd64_analyze_prologue): Check for `endbr64`
instruction, skip it if it's there.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-prologue-skip-cf-protection.exp: New file.
* gdb.arch/amd64-prologue-skip-cf-protection.c: New file.
|
|
When running test-case gdb.base/shlib-call.exp with clang, we get:
...
gdb compile failed, In file included from shmain.c:6:
unbuffer_output.c:39:1: warning:
control reaches end of non-void function [-Wreturn-type]
}
^
1 warning generated.
...
Fix this by changing the return-type to void.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* lib/unbuffer_output.c (gdb_unbuffer_output): Change return type to
void.
|
|
When running test-case gdb.base/consecutive.exp with gcc-8 instead of gcc-7,
we get:
...
(gdb) step^M
^M
-Breakpoint 3, 0x00000000004004b1 in foo () at consecutive.c:10^M
+Breakpoint 3, foo () at consecutive.c:10^M
10 return a[0] + a[1] + a[2] + a[3] + a[4] + a[5] + a[6];^M
-(gdb) PASS: gdb.base/consecutive.exp: stopped at bp, 2nd instr
+(gdb) FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr
...
This is due to the fact that gcc-8 generates more precise line info, making
the breakpoint address a "recommended breakpoint location", and consequently
gdb doesn't print the address prefix anymore.
Fix the FAIL by checking in the test-case whether the breakpoint address is at
"recommended breakpoint location" or not.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (is_stmt_addresses, hex_in_list): New proc, factored out
of ...
* gdb.base/async.exp: ... here.
* gdb.base/consecutive.exp: Handle if 2nd breakpoint is at a
"recommended breakpoint location".
|
|
When running test-case gdb.arch/i386-mpx.exp with gcc-10, we get:
...
Running src/gdb/testsuite/gdb.arch/i386-mpx.exp ...
gdb compile failed, xgcc: warning: switch '-mmpx' is no longer supported
xgcc: warning: switch '-fcheck-pointer-bounds' is no longer supported
...
The test-case uses a combination of options, -mmpx and -fcheck-pointer-bounds.
The -fcheck-pointer-bounds option requires the -mmpx option:
...
$ gcc -fcheck-pointer-bounds ~/hello.c
hello.c:1:0: warning: Pointer Checker requires MPX support on this target. \
Use -mmpx options to enable MPX.
#include <stdio.h>
cc1: error: ‘-fcheck-pointer-bounds’ is not supported for this target
...
Both options is no longer supported in gcc-9.
Fix the warnings by testing if the option combination is supported.
Tested on x86_64-linux, with gcc-7.5.0 and gcc-10.0.1.
gdb/testsuite/ChangeLog:
2020-05-02 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (supports_mpx_check_pointer_bounds): New proc.
* gdb.arch/i386-mpx-call.exp: Use supports_mpx_check_pointer_bounds.
* gdb.arch/i386-mpx-map.exp: Same.
* gdb.arch/i386-mpx-sigsegv.exp: Same.
* gdb.arch/i386-mpx-simple_segv.exp: Same.
* gdb.arch/i386-mpx.exp: Same.
|
|
With target board debug-types, we have these FAILs:
...
FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols
FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols
...
due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle
struct decl with DW_AT_signature".
Marks these as XFAILs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (debug_types): New proc.
* gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232.
* gdb.python/py-symtab.exp: Same.
|
|
When running test-case gdb.base/readnever.exp without commit 96038148d0e
"[gdb/testsuite] Skip gdb.base/readnever.exp with target board readnow", we
run into an error:
...
ERROR: (eof) GDB never initialized.
testcase gdb/testsuite/gdb.base/readnever.exp completed in 0 seconds
...
If we additionally run test-case gdb.base/realname-expand.exp, we get an
unresolved for the first test:
...
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Using -v we find out that the UNRESOLVED is due the error triggered in the
previous test-case:
...
(gdb) set basenames-may-differ on^M
(gdb) Error/Warning threshold exceeded: 1 0 (max. 1 3)
UNRESOLVED: gdb.base/realname-expand.exp: set basenames-may-differ on
...
So, the error count of one test spills into the next test, even though we do a
clean restart. That seems like a bad idea.
Fix this by resetting errcnt (as well as warncnt) in clean_restart, such that
we have:
...
Running src/gdb/testsuite/gdb.base/readnever.exp ...
ERROR: (eof) GDB never initialized.
Running src/gdb/testsuite/gdb.base/realname-expand.exp ...
PASS: gdb.base/realname-expand.exp: set basenames-may-differ on
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (clean_restart): Reset errcnt and warncnt.
|
|
When running test-case gdb.base/readnever.exp with target board readnow, and
without commit 96038148d0e "[gdb/testsuite] Skip gdb.base/readnever.exp with
target board readnow", we run into a bunch of errors, starting with:
...
spawn gdb -nw -nx -data-directory data-directory -ex set sysroot -readnow \
--readnever^M
gdb: '--readnow' and '--readnever' cannot be specified simultaneously^M
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re "$gdb_prompt $" {
verbose "Setting height to 0." 2
}
...
The illegal combination of --readnow and --readnever causes gdb to start,
print an error message and exit. There's a gdb_expect in default_gdb_start
that is supposed to detect the initial gdb prompt and handle related problems,
but since there's no eof case it succeeds, and default_gdb_start continues as
if the gdb prompt had been detected, causing the error above.
Fix this by adding an eof case to the gdb_expect, such that we have the more
accurate:
...
ERROR: (eof) GDB never initialized.
...
Further errors are triggered in clean_restart, because we're not testing for
gdb_start success. Fix this by detecting gdb_start failure, and bailing out.
Finally, we're running into further errors in gdb.base/readnever.exp because
we're not testing for clean_restart success. Fix this by making clean_restart
return -1 upon error, and testing for this.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_start): Handle eof.
(clean_restart): Detect and handle gdb_start failure. Return -1 upon
failure.
* gdb.base/readnever.exp: Handle clean_restart failure.
|
|
Consider the test-case added in this patch, with resulting dwarf:
...
Compilation Unit @ offset 0xc7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0><d2>: Abbrev Number: 2 (DW_TAG_partial_unit)
<d3> DW_AT_language : 2 (non-ANSI C)
<d4> DW_AT_name : imported_unit.c
<1><e4>: Abbrev Number: 3 (DW_TAG_base_type)
<e5> DW_AT_byte_size : 4
<e6> DW_AT_encoding : 5 (signed)
<e7> DW_AT_name : int
<1><eb>: Abbrev Number: 4 (DW_TAG_subprogram)
<ec> DW_AT_name : main
<f1> DW_AT_type : <0xe4>
<f5> DW_AT_external : 1
<1><f6>: Abbrev Number: 0
Compilation Unit @ offset 0xf7:
Length: 0x2c (32-bit)
Version: 4
Abbrev Offset: 0x85
Pointer Size: 8
<0><102>: Abbrev Number: 2 (DW_TAG_compile_unit)
<103> DW_AT_language : 2 (non-ANSI C)
<104> DW_AT_name : <artificial>
<1><111>: Abbrev Number: 3 (DW_TAG_subprogram)
<112> DW_AT_abstract_origin: <0xeb>
<116> DW_AT_low_pc : 0x4004a7
<11e> DW_AT_high_pc : 0x4004b2
<1><126>: Abbrev Number: 0
...
When run with target board cc-with-gdb-index, we run into:
...
(gdb) break main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1 at 0x4004ab
(gdb) PASS: gdb.dwarf2/imported-unit-runto-main.exp: setting breakpoint at main
run
Starting program: /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/imported-unit-runto-main/imported-unit-runto-main
warning: (Internal error: pc 0x4004a7 in read in CU, but not in symtab.)
<repeat>
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
Breakpoint 1, warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
0x00000000004004ab in main ()
warning: (Internal error: pc 0x4004ab in read in CU, but not in symtab.)
<repeat>
(gdb) FAIL: gdb.dwarf2/imported-unit-runto-main.exp: running to main in runto
...
Looking at the .gdb_index section contents using objdump --dwarf=gdb_index, we
have:
...
CU table:
[ 0] 0x0 - 0x2d
[ 1] 0x2e - 0xa4
[ 2] 0xa5 - 0xc6
[ 3] 0xf7 - 0x126
[ 4] 0x127 - 0x2de
[ 5] 0x2df - 0x300
Address table:
00000000004004a7 00000000004004b2 4
Symbol table:
[489] main: 4 [global, function]
...
We see that both the main symbol, and main address range map to CU 4, which has
offset range 0x127 - 0x2de, while main actually is contained in CU 3 at offset
range 0xf7 - 0x126.
This is caused by this continue in write_gdbindex, which triggers for the PU:
...
/* CU of a shared file from 'dwz -m' may be unused by this main file.
It may be referenced from a local scope but in such case it does not
need to be present in .gdb_index. */
if (psymtab == NULL)
continue;
...
The continue causes the PU to be skipped in the CU table (we can see that the
PU offset range 0xc7-0xf6 is missing) but the references are not taking that
into account.
I've tried fixing this in the optimal way, by updating the references, but ran
into trouble when follow_die_offset tries to find the CU for the inter-CU
ref. Because the PU is missing from the CU table,
dwarf2_find_containing_comp_unit bisects to the wrong CU.
Fix this by not skipping the PU in the CU table.
Build and reg-tested on x86_64-linux, with native and target boards
cc-with-gdb-index, cc-with-dwz and cc-with-dwz-m.
gdb/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* dwarf2/index-write.c (write_gdbindex): Generate CU table entries for
CUs without psymtab.
gdb/testsuite/ChangeLog:
2020-04-16 Tom de Vries <tdevries@suse.de>
PR symtab/25791
* gdb.dwarf2/gdb-add-index.exp (add_gdb_index): Move ...
(ensure_gdb_index): and factor out and move ...
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): ... here.
* gdb.dwarf2/imported-unit-runto-main.exp: New file.
|
|
Every time I write a test making use of the DWARF assembler I end up
copying in the function get_func_info. Duplicating code is bad, so
lets put this function into lib/dwarf.exp and remove all of the
duplicates.
There should be no changes in the testsuite behaviour after this
commit.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-many-frames.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-inline-small-func.exp: Pass options to
get_func_info.
(get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt-2.exp (get_func_info): Delete.
* gdb.dwarf2/dw2-is-stmt.exp (get_func_info): Delete.
* lib/dwarf.exp (get_func_info): New function.
|
|
When running test-case gdb.ada/catch_ex.exp using system gnatmake, gnatmake is
invoked like this:
...
Executing on host: \
gnatmake foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
When I try to use a more recent gnatmake, by mocking up a combined build:
...
$ ls -la build/gcc/
lrwxrwxrwx gfortran -> /usr/bin/gfortran-10
lrwxrwxrwx gnatbind -> /usr/bin/gnatbind-10
lrwxrwxrwx gnatlink -> /usr/bin/gnatlink-10
lrwxrwxrwx gnatmake -> /usr/bin/gnatmake-10
lrwxrwxrwx xg++ -> /usr/bin/g++-10
lrwxrwxrwx xgcc -> /usr/bin/gcc-10
...
gnatmake is invoked like this:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatmake \
-I/data/gdb_versions/devel/build/gcc/ada/rts \
--GCC=/data/gdb_versions/devel/build/gcc/xgcc \
--GNATBIND=/data/gdb_versions/devel/build/gcc/gnatbind \
--GNATLINK=/data/gdb_versions/devel/build/gcc/gnatlink \
-cargs -B/data/gdb_versions/devel/build/gcc \
-largs --GCC=/data/gdb_versions/devel/build/gcc/xgcc \
-B/data/gdb_versions/devel/build/gcc \
-margs foo.adb -gnata -f -Isrc/gdb/testsuite/gdb.ada/catch_ex -g -lm \
-o outputs/gdb.ada/catch_ex/foo
...
This is set up by this bit in find_gnatmake in
/usr/share/dejagnu/libgloss.exp:
...
if {![is_remote host]} {
set file [lookfor_file $tool_root_dir gnatmake]
if { $file == "" } {
set file [lookfor_file $tool_root_dir gcc/gnatmake]
}
if { $file != "" } {
set root [file dirname $file]
set CC "$file -I$root/ada/rts --GCC=$root/xgcc \
--GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink \
-cargs -B$root \
-largs --GCC=$root/xgcc -B$root -margs"
} else {
...
However, when running test-case gdb.ada/catch_ex_std.exp using the mockup
combined build, we get:
...
Executing on host: \
/data/gdb_versions/devel/build/gcc/gnatlink foo \
-Wl,-rpath,\$ORIGIN -Wl,-lsome_package
b~foo.adb:26:79: "SS_Stack" not declared in "Secondary_Stack"^M
b~foo.adb:26:89: incorrect constraint for this kind of type^M
b~foo.adb:121:56: "Runtime_Default_Sec_Stack_Size" not declared in "Parameters"^M
FAIL: gdb.ada/catch_ex_std.exp: gnatlink foo
...
The problem is caused by the fact that the test uses gnatlink directly
rather than using gnatmake. The invoked gnatlink (which is gnatlink-10) calls
gcc-7, which are incompatible (see gcc PR86211). This problem doesn't occur
with gnatmake because there the gcc to use is passed as an argument to
gnatlink.
Fix this by adding the -largs bit from find_gnatmake in find_ada_tool, for the
case that $tool == gnatlink.
Tested on x86_64-linux, with system gcc, and gcc-10.
gdb/testsuite/ChangeLog:
2020-04-13 Tom de Vries <tdevries@suse.de>
* lib/ada.exp (find_ada_tool): Pass --GCC and -B to gnatlink, similar
to what find_gnatmake does.
|
|
The test-case gdb.dwarf2/imported-unit.exp contains a test testing partial
symbols, so when we run the test-case using either target board readnow,
cc-with-gdb-index or cc-with-debug-names, we run into:
...
FAIL: gdb.dwarf2/imported-unit.exp: no static partial symbols in importing unit
...
Fix this by marking the test unsupported if there are no partial symbols.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-08 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (psymtabs_p): New proc.
* gdb.dwarf2/imported-unit.exp: Mark "no static partial symbols in
importing unit" unsupported if there are no partial symbols.
|
|
Extend the Dejagnu DWARF compiler to support DW_LNS_set_file opcode.
This will be used in a later commit. There should be no change in the
testsuite after this commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::lines::program::DW_LNS_set_file): New
function.
|
|
When using the Dejagnu DWARF compiler tests will often use the
function_range helper function to extract the extents of a function.
If the plan is to compiler the file with non-default compiler flags
then we must pass those same compiler flags through to the
function_range helper function.
This will be used in a later commit, there should be no change in the
testsuite behaviour after this commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (function_range): Allow compiler options to be
specified.
|
|
While running test-case gdb.multi/multi-target.exp, I observed a silent
timeout related to "monitor exit".
By making the timeout explicit in an expect clause in gdbserver_gdb_exit:
...
+ timeout {
+ warning "Timed out waiting for EOF in server after $monitor_exit"
+ }
...
we get in the log:
...
monitor exit^M
"monitor" command not supported by this target.^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
What happens is the following:
- the inferior 5 is selected
- a breakpoint is set in inferior 1
- the breakpoint triggers and we switch to inferior 1
- setup is called by test_continue, which calls clean_restart, which calls
gdbserver_gdb_exit (due to load_lib gdbserver-support.exp)
- gdbserver_gdb_exit issues "monitor exit"
- gdb responds with "not supported by this target" because inferior 1 is
native
Fix this by keeping a list of server_spawn_id, and cleaning those up before
calling gdbserver_gdb_exit.
This reduces testing time from 1m22s to 32s.
gdb/testsuite/ChangeLog:
2020-04-02 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdbserver_exit): Factor out of ...
(gdbserver_gdb_exit): ... here. Add timeout warning.
* gdb.multi/multi-target.exp (server_spawn_ids): New global var.
(connect_target_extended_remote): Append new server_spawn_id to
server_spawn_ids.
(cleanup): New proc.
(setup, <toplevel>): Call cleanup.
|
|
When running test-case gdb.base/c-linkage-name.exp with target board
cc-with-gdb-index.exp, I see:
...
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes
...
The FAILs are due to the fact that partial symbol tables are not generated for
indexed executables.
When running the same test-case with target board readnow.exp, I see:
...
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: no
FAIL: gdb.base/c-linkage-name.exp: print symada__cS before partial symtab \
expansion
FAIL: gdb.base/c-linkage-name.exp: maint info psymtab: c-linkage-name-2.c: yes
...
The "maint info psymtab" FAILs are also due to fact that the partial symbol
tables not generated, but in this case it's because the symtabs are fully
expanded upon load due to using -readnow. The "print symada__cS before
partial symtab expansion" test intends to test the state before symbol table
expansion, and with -readnow that's not possible.
Mark these FAILs as UNSUPPORTED.
Tested on x86_64-linux, with native, and target boards cc-with-gdb-index.exp,
cc-with-debug-names.exp and readnow.exp.
gdb/testsuite/ChangeLog:
2020-03-30 Tom de Vries <tdevries@suse.de>
* gdb.base/c-linkage-name.exp: Use readnow call to mark a test
unsupported.
(verify_psymtab_expanded): Move ...
* lib/gdb.exp (verify_psymtab_expanded): ... here. Add unsupported
test.
(readnow): New proc.
|
|
When running test-case gdb.threads/omp-par-scope.exp, I get this XPASS:
...
XPASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: \
outer stop: get valueof "num"
...
for test:
...
set thread_num [get_valueof "" "num" "unknown"]
...
The intention of the test is to get the value of local variable num, which
has been set to:
...
int num = omp_get_thread_num ();
...
but the actually printed value is 'num':
...
(gdb) print num^M
$76 = num^M
...
This is due to the fact that num is missing in the locals, so instead we find
the enum member 'num' of enum expression_operator in glibc/intl/plural-exp.h.
Fix this by getting the value using a new proc get_local_valueof, which uses
the "info locals" commands to get the value.
Tested on x86_64-linux, with gcc 7.5.0 (where the test xfails) and gcc
10.0.1 (where the test passes).
|
|
When running test-case gdb.linespec/cpcompletion.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into lots of
timeouts, in particular with this pattern:
...
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_st" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_st"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_str" (timeout)
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
cmd complete "b template2_str"
FAIL: gdb.linespec/cpcompletion.exp: template-ret-type: \
tab complete "b template2_stru" (timeout)
...
Fix this by detecting timeouts in test_complete_prefix_range_re and giving up
after 3 consecutive timeouts.
This reduces testing time from ~39m to ~9m.
Tested on x86_64-linux.
|
|
Test-case gdb.base/gdb-caching-proc.exp tests whether procs declared using
gdb_caching_proc give the same results when called more than once.
While this tests consistency of the procs in the context of that test-case, it
doesn't test consistency across the call sites.
Add a local variable cache_verify to proc gdb_do_cache, that can be set to 1
to verify gdb_caching_proc consistency across the call sites.
Likewise, add a local variable cache_verify_proc to set to the name of the
gdb_caching_proc to verify. This can f.i. be used when changing an existing
proc into a gdb_caching_proc.
Tested on x86_64-linux, with cache_verify set to both 0 and 1.
gdb/testsuite/ChangeLog:
2020-03-16 Tom de Vries <tdevries@suse.de>
* lib/cache.exp (gdb_do_cache): Add and handle local variables
cache_verify and cache_verify_proc.
|
|
message
When running testcase gdb.cp/step-and-next-inline.exp, I get:
...
Running src/gdb/testsuite/gdb.cp/step-and-next-inline.exp ...
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
gdb compile failed, g++: error: unrecognized debug output level \
'statement-frontiers'
=== gdb Summary ===
# of untested testcases 2
...
Fix this by using a new gdb_caching_proc supports_statement_frontiers.
Tested on x86_64-linux, with gcc 7.5.0 (which does not support
-gstatement-frontiers) and with gcc 8.4.0 (which does support
-gstatement-frontiers).
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (supports_statement_frontiers): New proc.
* gdb.cp/step-and-next-inline.exp: Use supports_statement_frontiers.
|
|
With test-case gdb.tui/corefile-run.exp and make target check-read1, I run
into:
...
FAIL: gdb.tui/corefile-run.exp: run until the end
...
In more detail, using -v:
...
PASS: gdb.tui/corefile-run.exp: load corefile
^M+++ _ctl_0x0d
^[[17d+++ _csi_d <<<17>>>
^[[M+++ _csi_M <<<>>>
^[[24d+++ _csi_d <<<24>>>
(INSERT <<(>>
gINSERT <<g>>
dINSERT <<d>>
bINSERT <<b>>
)INSERT <<)>>
INSERT << >>
FAIL: gdb.tui/corefile-run.exp: run until the end
...
With some debugging code added in wait_for, what happens becomes more clear:
...
if {[regexp -- $wait_for $prev]} {
+ verbose -log "\nwait_for: MATCHED line ($_cur_y): \"$prev\""
+ verbose -log "wait_for: AGAINST regexp: \"$wait_for\""
...
In corefile-run.exp, we execute:
...
Term::command "run"
...
and in proc Term::command, we send the command, and then call wait_for:
...
proc command {cmd} {
send_gdb "$cmd\n"
wait_for [string_to_regexp $cmd]
}
...
which first waits for the command string, and then for the prompt.
In this case however, the matching of the command string triggers on a
previous line:
...
wait_for: MATCHED line (16): \
"(gdb) core-file corefile-run.core[New LWP 6426] <lots-of-spaces>"
wait_for: AGAINST regexp: "run"
...
and from there on things go out of sync, eventually resulting in the FAIL.
Fix this in proc command by more precisely specifying the expected pattern:
adding a ^$gdb_prompt prefix.
Add a command_no_prompt_prefix variant to use for initial terminal commands
where there's no prompt yet.
Tested gdb.tui/*.exp on x86_64-linux, with make target check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-13 Tom de Vries <tdevries@suse.de>
* lib/tuiterm.exp (Term::command_no_prompt_prefix): New proc.
(Term::command): Use prompt prefix.
(Term::enter_tui): Use command_no_prompt_prefix instead of prefix.
* gdb.tui/tui-layout-asm-short-prog.exp: Use
command_no_prompt_prefix instead of prefix.
* gdb.tui/tui-layout-asm.exp: Same.
|
|
In commit 1281424ccf "[gdb/testsuite] Fix core file load FAIL in
tls-core.exp", I've made this change:
...
- -re ": No such file or directory.*\r\n$gdb_prompt $" {
+ -re "$core: No such file or directory.*\r\n$gdb_prompt $" {
...
However, the $core variable contains a filename which needs to be matched
as a literal string, not as a regexp.
Fix this by using string_to_regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_core_cmd): Use string_to_regexp for regexp-matching
$core.
|
|
After deinstalling package glibc-debugsource, I run into the following FAIL
with test-case gdb.threads/tls-core.exp:
...
(gdb) core gdb/testsuite/outputs/gdb.threads/tls-core/tls-core.core^M
[New LWP 30081]^M
[New LWP 30080]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Core was generated by `gdb/testsuite/outputs/gdb.threads/tls-core/tls-c'.^M
Program terminated with signal SIGABRT, Aborted.^M
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.^M
[Current thread is 1 (Thread 0x7fb568d4b700 (LWP 30081))]^M
(gdb) FAIL: gdb.threads/tls-core.exp: native: load core file (file not found)
...
The problem is that this gdb_test_multiple clause in gdb_core_cmd:
...
-re ": No such file or directory.*\r\n$gdb_prompt $" {
fail "$test (file not found)"
return -1
}
...
triggers on the message about raise.c, while it is intended to catch:
...
$ gdb
(gdb) core bla
/home/vries/bla: No such file or directory.
...
Fix this by making the regexp more precise:
...
- -re ": No such file or directory.*\r\n$gdb_prompt $" {
+ -re "$core: No such file or directory.*\r\n$gdb_prompt $" {
...
Tested on x86_64-linux.
Also tested the test-case with this patch in place to verify that the regexp
still triggers:
...
- set core_loaded [gdb_core_cmd $corefile $test]
+ set core_loaded [gdb_core_cmd $corefile/bla $test]
...
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_core_cmd): Make "No such file or directory" regexp
more precise.
|
|
When on a MinGW host, standard_output_file uses a regular expression to
convert Unix-style paths of the form "/c/foo" to "c:/foo". This is
needed because the paths we pass to GDB (for example, with the "file"
command) need to be in the Windows form.
However, the regexp only works if your binutils-gdb repo is under a
`/[a-z]/...` path (the Unix paths mapping to Windows drives).
Presumably, that works if you clone the repo in Windows, then access it
through `/c/...`.
In my case, I've cloned the repository directly inside my MinGW shell,
so in /home/smarchi. The regexp therefore doesn't work for me. The
path doesn't get transformed, and the file command fails when running
any test:
(gdb) file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent: No such file or directory.
A safer way to do this is to execute `pwd -W` while in the directory we
want the path for, this is what this patch does.
I have also considered using the using the cygpath utility to do the
conversion. It can be used to convert any MinGW path into its Windows
equivalent. Despite originally coming from Cygwin, the cygpath utility
is distributed by MinGW-w64 and can be used in that environment.
However, it's not distributed with the non-MinGW-w64 MinGW.
The `pwd -W` trick only works with directories that exist, which is the
case here, so it's sufficient.
With this, the file command in the test succeeds:
(gdb) file C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent
Reading symbols from C:/msys64/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.arch/i386-bp_permanent/i386-bp_permanent...
gdb/testsuite/ChangeLog:
* lib/gdb.exp (standard_output_file): Use `pwd -W` to convert
from Unix to Windows path.
|
|
This commit adds the ability to set and toggle the DWARF line table
is-stmt flag.
A DWARF line table can now be created with the attribute
'default_is_stmt' like this:
lines {version 2 default_is_stmt 0} label {
...
}
If 'default_is_stmt' is not specified then the current default is 1,
which matches the existing behaviour.
Inside the DWARF line table program you can now make use of
{DW_LNS_negate_stmt} to toggle the is-stmt flag, for example this
meaningless program:
lines {version 2 default_is_stmt 0} label {
include_dir "some_directory"
file_name "some_filename" 1
program {
{DW_LNS_negate_stmt}
{DW_LNE_end_sequence}
}
}
This new functionality will be used in a later commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::lines) Add support for modifying the
is-stmt flag in the line table.
Change-Id: Ia3f61d523826382dd2333f65b9aae368ad29c4a5
|
|
When trying to run tests using target board cc-with-dwz after a clean build, I
run into:
...
ERROR: tcl error sourcing board description file for target cc-with-tweaks.exp.
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
no such file or directory
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
no such file or directory
while executing
"open $tmp_filename w"
(procedure "cached_file" line 9)
invoked from within
"cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1"
...
The problem is that cached_file is trying to create a file
build/gdb/testsuite/cache/gdb.sh.17028 in a non-existing directory.
Fix this by creating the cache dir in cached_file.
Tested on x86_64-linux, with target board cc-with-tweaks, and native.
gdb/testsuite/ChangeLog:
2020-03-09 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (cached_file): Create cache dir.
|
|
When using target board cc-with-gdb-index.exp and running tests in parallel,
we run into:
...
gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \
build/gdb/testsuite/gdb.sh: Text file busy
...
The problem is that because of the parallel test run, gdb.sh is created for
every single test-case, and eventually gdb.sh is overwritten while being
executed.
Fix this by creating gdb.sh only once.
Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a
serial and parallel -j 5 test run.
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (tentative_rename, cached_file): New proc.
* boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.
|
|
In lib/fortran.exp, in the helper function fortran_int4, kind
parameter is expected to be printed as (kind=4) for the LLVM
Fortran compiler, Flang along with gfortran. And in the helper
function fortran_int8 kind parameter is expected to be printed
as (kind=8). But for the Flang compiler default kind is not
printed and non default kind is printed differently than gfortran
as below.
integer(kind=4) => integer
integer(kind=8) => integer*8
real(kind=4) => real
real(kind=8) => double precision
complex(kind=4) => complex
logical(kind=4) => logical
character(kind=1) => character
This commit adds support for printing of kind parameter for the
Flang. There should be no change when testing with gfortran.
Note: The current patch overrides earlier patch with below details.
commit c3b149eb7697b376df1b3a47d0102afda389ee6d
Author Alok Kumar Sharma (alokkumar.sharma@amd.com)
Earlier patch was incomplete and based on assumption that flang
should be changed to dump a type with kind like the way gfortan does.
Later it was realized that the way flang dumps this info is not
incorrect but different. And changes in gdb test framework are
finalized.
gdb/testsuite/ChangeLog:
* lib/fortran.exp (fortran_int4): Handle flang kind printing.
(fortran_int8): Likewise.
(fortran_real4): Likewise.
(fortran_real8): Likewise.
(fortran_complex4): Likewise.
(fortran_logical4): Likewise.
(fortran_character1): Likewise.
|
