| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In gdb_default_target_compile, we use dejagnu's default_target_compile, unless
we need support for languages that are not yet support in the used dejagnu
version, in which case we use a local default_target_compile:
gdb_default_target_compile_1.
However, there's another reason to use the local default_target_compile: when
early_flags is used, because there's no dejagnu release available yet
supporting this.
Fix this by detecting and handling early_flags in gdb_default_target_compile.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-30 Tom de Vries <tdevries@suse.de>
PR testsuite/26175
* lib/future.exp (gdb_default_target_compile): Detect and handle
early_flags.
|
|
Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
command in test-case" we don't abort the testrun when encountering an invalid
command. However, since we don't report errors in the summary, there's a
chance that the error goes unnoticed.
Make the invalid command error more visible by marking the test-case
unresolved, such that we have f.i.:
...
PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
testcase aborted due to invalid command name: gdb_py_test_multiple
ERROR: tcl error sourcing py-breakpoint.exp.
ERROR: invalid command name "gdb_py_test_multiple"
while executing
...
=== gdb Summary ===
nr of expected passes 56
nr of unresolved testcases 1
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-29 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (unknown): Make test-case unresolved.
|
|
Version 2, handles the comments of Simon and Pedro.
Note that gdb_test_multiline and gdb_py_test_multiple are using
the "input line" as the test name, and so when there is a duplicated
input line (such as a line containing "end"), we have duplicated test
names => as gdb_test_multiline and gdb_py_test_multiple are identical,
as indicated in FIXME, move this to gdb.exp, and make the test name unique
by adding the inputnr to the pass message for each input.
2020-06-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* lib/gdb.exp (gdb_test_multiline): New, moved from gdb-guile.exp,
have a input seq nr in each pass message.
* lib/gdb-guile.exp (gdb_test_multiline): Move to gdb.exp.
* lib/gdb-python.exp (gdb_py_test_multiple): Remove.
* gdb.python/python.exp: Make test names unique,
use gdb_test_multiline instead of gdb_py_test_multiple,
use $gdb_test_name.
* gdb.guile/guile.exp: Make test names unique, use $gdb_test_name
|
|
This fixes test runs and compilation when --disable-libctf,
--disable-static, or --enable-shared are passed.
Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype
using 'void'. Use 'unsupported' and gdb_caching_proc.
Changes since v3: Adapt to upstream changes providing skip_ctf_tests.
Changes since v4: Adapt to upstream changes in the seven months (!)
since I last looked at this.
gdb/ChangeLog
* configure.ac: Add --enable-libctf: handle --disable-static
properly.
* acinclude.m4: sinclude ../config/enable.m4.
* Makefile.in (aclocal_m4_deps): Adjust accordingly.
(LIBCTF): Substitute in.
(CTF_DEPS): New, likewise.
(CLIBS): libctf needs symbols from libbfd: move earlier.
(CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath
flags.
* ctfread.c: Surround in ENABLE_LIBCTF.
(elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub.
* configure: Regenerate.
* config.in: Likewise.
gdb/testsuite/ChangeLog
* configure.ac: Add --enable-libctf.
* aclocal.m4: sinclude ../config/enable.m4.
* Makefile.in (site.exp): Add enable_libctf to site.exp.
* lib/gdb.exp (skip_ctf_tests): Use it.
* gdb.base/ctf-constvars.exp: Error message tweak.
* gdb.base/ctf-ptype.exp: Likewise.
* configure: Regenerate.
|
|
Some testcases want to compile .c files with a C++ compiler. So they
pass the "c++" option to gdb_compile. That works fine with GCC, but
with Clang, it results in:
gdb compile failed, clang-5.0: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
and the testcase is skipped with UNTESTED.
A previous patch fixed a case like that in
gdb.compile/compile-cplus.exp, by adding -Wno-deprecated to the build
options. However, there are other testcases that use the same
pattern, and all fail for the same reason. For example:
gdb.base/info-types-c++.exp
gdb.base/max-depth-c++.exp
gdb.base/msym-lang.exp
gdb.base/whatis-ptype-typedefs.exp
gdb.btrace/rn-dl-bind.exp
Fix this in a central place, within gdb_compile, by passing "-x c++"
to the compiler driver when we're compiling/linking C++.
This revealed that gdb.compile/compile-cplus.exp and
gdb.arch/amd64-entry-value-paramref.exp tests are compiling an
assembly file with the "c++" option, which would now fail to compile,
with the C++ compiler not grokking the assembly, of course. We just
need to not pass "c++" and all the other related C++ options when
compiling an assembly file.
gdb/testsuite/ChangeLog:
2020-06-24 Pedro Alves <palves@redhat.com>
* gdb.arch/amd64-entry-value-paramref.exp: Use
prepare_for_testing_full and don't pass "c++" for the .S file
build spec.
* gdb.compile/compile-cplus.exp: Don't compile $srcfile3 with
$options, since it's an assembly file. Remove -Wno-deprecated.
* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
compiling C++ programs.
|
|
Some C/C++ testcases unconditionally pass -Wno-foo as additional
options to disable some warning. That is OK with GCC, because GCC
accepts -Wno-foo silently even if it doesn't support -Wfoo. This is a
feature which allows disabling warnings with newer compilers without
breaking builds with older compilers. Clang however warns about
unknown -Wno-foo by default, unless you pass
-Wno-unknown-warning-option as well:
$ gcc -Wno-foo test.c
* nothing, compiles successfuly *
$ clang -Wno-foo test.c
warning: unknown warning option '-Wno-foo [-Wunknown-warning-option]
This commit adds -Wunknown-warning-option centrally in gdb_compile, so
that individual testcases don't have to worry about breaking older
Clangs.
IOW, this avoids this problematic scenario:
#1 - A testcase compiles successfully with Clang version X.
#2 - Clang version "X + 1" adds a new warning, enabled by default,
which breaks the test.
#3 - We add -Wno-newwarning to the testcase, fixing the testcase with
clang "X + 1".
#4 - Now building the test with Clang version X no longer works, due
to "unknown warning option".
gdb/testsuite/ChangeLog:
2020-06-24 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_compile): Update intro comment. If C/C++ with
Clang, add "-Wno-unknown-warning-option" to the options.
|
|
The history-scrolling commands "+", "-", "<" and ">" are only known to
GDB when TUI is enabled. This means the "complete pipe " command
produces different output depending on whether TUI is present, which
in turn caused
FAIL: gdb.base/shell.exp: cmd complete "pipe "
This patch provides different patterns for that test depending on
whether or not TUI is available.
2020-06-23 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* lib/completion-support.exp (test_gdb_completion_offers_commands):
Adjust for omitted commands when TUI is disabled.
|
|
The file lib/future.exp contains an override of dejagnu's
default_target_compile.
The override is activated if dejagnu's default_target_compile is missing
support for one or more languages.
However, if the override is activated, it's active for all languages.
This unnecessarily extends the scope of potential problems in the override to
languages that don't need the override.
Fix this by limiting the scope of the override.
Also add a note stating for which languages the override is active, as a
reminder that support for those languages needs to be ported to dejagnu. With
my system dejagnu 1.6.1, as well as with current dejagnu trunk, that gives us:
...
NOTE: Dejagnu's default_target_compile is missing support for Go, using \
local override
NOTE: Dejagnu's default_target_compile is missing support for Rust, using \
local override
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-19 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_note): New proc.
* lib/future.exp (gdb_default_target_compile_1): Factor out of ...
(gdb_default_target_compile): ... here. Only call
gdb_default_target_compile_1 if use_gdb_compile(<lang>) is set.
(use_gdb_compile): Change to array.
(toplevel): Update sets of use_gdb_compile to specify language.
Warn about default_target_compile override. Store dejagnu's version
of default_target_compile in dejagnu_default_target_compile.
|
|
If a baseboard file wants to override a proc foo, but also use the original
proc, it'll have to do something like:
...
rename foo save_foo
proc foo { } {
...
set res [save_foo]
...
return res
}
...
This adds a new proc named save_foo, which introduces the risk of clashing with
an existing proc.
There's a pattern in the gdb testsuite procs, that facilitates this override:
...
proc default_foo { } {
...
}
proc foo { } {
return [default_foo]
}
...
such that in a baseboard file we don't need the rename:
...
proc foo { } {
...
set res [default_foo]
...
return res
}
...
The exception to the pattern though is gdb_init, which has a default_gdb_init
counterpart, but contains much more code than just the call to
default_gdb_init.
Fix this by moving all but the call to default_gdb_init to default_gdb_init.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-18 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_init): Move all but call to default_gdb_init to ...
(default_gdb_init): ... here.
|
|
In gdb_init we install a local version of ::unknown, which relies on
::tcl_unknown, which is defined by dejagnu.
This proc may be moved into a namespace, or disappear altogether, as
indicated by dejagnu maintainers, so we can't rely on it.
Fix this by recreating tcl's version of unknown, and using that instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-17 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_tcl_unknown): New proc.
(gdb_init): Use gdb_tcl_unknown for ::unknown override. Make override
conditional on presence of gdb_tcl_unknown.
(gdb_finish): Make override undo conditional on presence of
gdb_tcl_unknown.
|
|
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.
|
