| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
|
|
Currently for the target board remote-gdbserver-on-localhost we use the
gdbserver file on build, using a file name which includes "/../".
Fix this by using a normalized file name instead.
This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
- remote_exec build "chmod go-rx $objdir/outputs"
+ remote_exec build "chmod go-rx $objdir"
...
Tested on x86_64-linux.
|
|
As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.
So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?
The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.
For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ... -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...
Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.
We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.
And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
version_id_main=0: continue to STOP marker
...
Tested on x86_64-linux.
Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>
|
|
When running test-case gdb.server/multi-ui-errors.exp on target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: connect to gdbserver
continue^M
Continuing.^M
PASS: gdb.server/multi-ui-errors.exp: continue - extra UI
Remote debugging from host ::1, port 35466^M
FAIL: gdb.server/multi-ui-errors.exp: ensure inferior is running
...
The problem is that the target board uses ssh -T, which fails to guarantee
that output from the inferior will be available.
Fix this by copying proc ${board}_spawn from local-remote-host.exp, which
ensures using ssh -t. [ It would be nice to define an ssh base board to
get rid of the copies, but I'm not addressing that in this commit. ]
Likewise for target board remote-stdio-gdbserver.exp.
Tested on x86_64-linux.
|
|
The usage for board remote-stdio-gdbserver.exp is advertised as:
...
# bash$ make check RUNTESTFLAGS="--target_board=remote-stdio-gdbserver \
# REMOTE_USERNAME=... REMOTE_HOSTNAME=... REMOTE_PORTNUM=... \
# [REMOTE_TMPDIR=${remote_dir}] [GDBSERVER=${remote_gdbserver}]"
...
but when adding REMOTE_PORTNUM=22, I run into:
...
Running stop-reply-no-thread-multi.exp ...
ERROR: tcl error sourcing stop-reply-no-thread-multi.exp.
ERROR: couldn't execute "/usr/bin/ssh -p22": no such file or directory
while executing
"builtin_spawn {/usr/bin/ssh -p22} -l vries localhost {/usr/bin/gdbserver \
--once localhost:2346 \
/home/vries/gdb_versions/devel/build/gdb/testsuite/outp..."
...
Fix this by simply removing REMOTE_PORTNUM.
Tested on x86_64-linux.
|
|
Propagate fix from commit 17c68d98f74 ("[gdb/testsuite] Disable styling in host
board local-remote-host.exp") to local-remote-host-native.exp.
Tested on x86_64-linux.
|
|
Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d
("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which
means the board now uses a pseudo-tty, but with editing disabled.
|
|
Add a file gdb/testsuite/boards/README, to make it easier to get a high-level
overview of the various boards.
|
|
With test-case gdb.server/stop-reply-no-thread-multi.exp and host board
local-remote-host-notty.exp we occasionally run into a silent out, due to
getting:
...
(gdb) kill^M
(gdb) The program is not being run.^M
...
instead of the expected:
...
(gdb) kill^M
The program is not being run.^M
(gdb)
...
Likewise, we occasionally run into a nonsilent timeout:
...
(gdb) disconnect^M
(gdb) You can't do that when your target is `exec'^M
FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \
disconnect (timeout)
...
Typically, this results in the test-case taking more than two minutes to run.
The problem can be reproduced using just:
...
$ ssh -l $USER 127.0.0.1 gdb -q -ex kill
...
Note that ssh by default uses -T which disables pseudo-tty allocation (as
opposed to -t which forces pseudo-tty allocation):
...
$ ssh -l $USER 127.0.0.1 -T tty
not a tty
$ ssh -l $USER 127.0.0.1 -t tty
/dev/pts/5
Connection to 127.0.0.1 closed.
...
and according to https://stackoverflow.com/a/63241102 the behaviour we're
seeing is specific to using '-T'.
The related host board local-remote-host.exp does use '-t', and the only
difference between the two boards mentioned is whether editing is on or off.
Fix this by:
- moving the content of local-remote-host-notty.exp into
local-remote-host.exp
- consequently, extending the copyright years in local-remote-host.exp
- including local-remote-host.exp in local-remote-host-notty.exp
(making local-remote-host-notty.exp use '-t')
- adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp
This results in the test-case taking just 6 seconds to run.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29669
|
|
With test-case gdb.server/stop-reply-no-thread.exp and host board
local-remote-host.exp, I run into:
...
Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M
21 ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M
(gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \
continue to main
...
The problem is that styling is enabled, and that is causing a regexp mismatch.
With native, styling is disabled in default_gdb_init by doing
'setenv TERM "dumb"', but that only has effect because the build (where we
execute runtest, and consequently the setenv) and the host (where we execute
gdb) are the same. For this host board however, gdb executes on a remote
host, and the setenv has no effect.
We could try to make some generic way to set TERM on the host, but for the
purposes of this test-case it seems sufficient to just add:
...
set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\""
...
so let's go with that for now.
Tested on x86_64-linux.
|
|
The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit
commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
Author: Tom Tromey <tromey@redhat.com>
Date: Wed Jun 29 17:50:47 2011 +0000
over 10 years ago. The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.
The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones. It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand. We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated. So, with this commit we remove the remaining lines for
its support.
|
|
When running with the native-extended-gdbserver board, I currently see
one failure in gdb.mi/mi-exec-run.exp:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
In this test the MI interface should be started in a separate tty,
which means we should have a CLI tty and an MI tty, however, this is
not happening. Instead GDB is just started in MI mode and there is no
CLI tty.
The test script tries to switch between the CLI an MI terminals and
look for some expected output on each, however, as there is no CLI
terminal the expected output never arrives, and the test times out.
It turns out that this is not a GDB problem, rather, this is an issue
with argument passing within the test script.
The proc default_mi_gdb_start expects to take a set of flags (strings)
as arguments, each of flag is expected to be a separate argument. The
default_mi_gdb_start proc collects all its arguments into a list using
the special 'args' parameter name, and then iterates over this list to
see which flags were passed.
In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
are also gathered into the 'args' parameter list, but are then
expanded back to be separate arguments using the eval trick, i.e.:
proc mi_gdb_start { args } {
return [eval default_mi_gdb_start $args]
}
This ensures that when we arrive in default_mi_gdb_start each flag is
a separate argument, rather than appearing as a single list containing
all arguments.
When using the native-extended-gdbserver board however, the file
boards/native-extended-gdbserver.exp is loaded, and this file replaces
the default mi_gdb_start with its own version.
This new mi_gdb_start also gathers the arguments into an 'args' list,
but forgets to expand the arguments out using the eval trick.
As a result, when using the native-extended-gdbserver board, by the
time we get to default_mi_gdb_start, we end up with the args list
containing a single item, which is a list containing all the arguments
the user passed.
What this means is that if the user passes two arguments, then, in
default_mi_gdb_start, instead of seeing two separate arguments, we see
a single argument made by concatenating the two arguments together.
The only place this is a problem is in the test mi-exec-run.exp,
which (as far as I can see) is the only test where we might try to
pass both arguments at the same time. Currently we think we passed
both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
arguments were passed.
This commit fixes the problem by making use of the eval trick within
the native-extended-gdbserver version of mi_gdb_start. After this,
the FAIL listed at the top of this message is resolved.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
The comment on top of gdb/testsuite/boards/remote-stdio-gdbserver.exp says
that user can specify path to gdbserver on remote system by setting
GDBSERVER variable. However, this variable was ignored and /usr/bin/gdbserver
was used unconditionally.
This commit updates the code to respect GDBSERVER if set and fall back to
/usr/bin/gdbserver if not.
|
|
Add a new target board dwarf64.exp, that runs test with -gdwarf64.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/batch-exit-status.exp with target board
native-gdbserver, I run into (added missing double quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
-data-directory $build/gdb/testsuite/../data-directory \
-iex "set height 0" -iex "set width 0" \
-ex "set auto-connect-native-target off" \
-iex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 3] == $expect_status
...
As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
local-board.exp", the problem is the use of -ex for
"set auto-connect-native-target off", which makes that the last command to
be executed, and consequently determines the return status.
Fix this by using -iex instead.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/batch-exit-status.exp for native, it passes.
But with target board cc-with-debug-names, we run into (added missing double
quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
-data-directory $build/gdb/testsuite/../data-directory \
-iex "set height 0" -iex "set width 0" -ex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: \
: No such file or directory\.: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: \
: No such file or directory\.: [lindex $result 3] == $expect_status
...
The difference between the passing and failing case is that with native we
have (leaving out set height/width for brevity):
...
$ gdb -batch ""; echo $?
: No such file or directory.
1
...
and with target board cc-with-debug-names:
...
$ gdb -ex "set sysroot" -batch ""; echo $?
: No such file or directory.
0
...
The difference is expected. GDB returns the exit status of the last executed
command. In the former case that's 'file ""', which fails. In the latter case,
that's 'set sysroot', which succeeds.
Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such
that we have the expected:
...
$ gdb -iex "set sysroot" -batch ""; echo $?
: No such file or directory.
1
...
Tested on x86_64-linux.
|
|
Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into a
seperate .debug file and links to it using .gnu_debuglink.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* contrib/cc-with-tweaks.sh: Handle -l.
gdb/testsuite/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* boards/cc-with-gnu-debuglink.exp: New file.
|
|
By default, when using the -g switch, avr-gcc generates stabs debug
information. I think it would make more sense to test GDB against DWARF
information, because stabs is obsolete by now, and nobody work on it.
So change the simavr board to pass -gdwarf-4 as the debug flag.
The downside is that users are probably more likely to use just -g, so
we don't test GDB the same way as users are likely to use it. But in
this case, if somebody comes and asks for help with GDB for AVR, I
suggest we encourage them to use -gdwarf-4.
I can't give stats about how that changes test results, because the
testsuite is too broken. There is an internal error that happens quite
frequently that needs to be investigated:
/home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.
I sent a question on the gcc mailing list, asking why stabs is the
default:
https://gcc.gnu.org/pipermail/gcc/2021-April/235309.html
gdb/testsuite/ChangeLog:
* boards/simavr.exp: Set debug_flags.
Change-Id: I70e471fad3a79ab1d79d13dda8436bb9eb666e0a
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
This patch makes a few adjustments to the simavr.exp to handle tests
that error out more gracefully. I put all the changes in the same patch
because right now it's in a very bad shape, so it's very painful to do
small incremental adjustements. I found that with these changes, it
becomes reasonably stable.
For example, the gdb.base/step-over-syscall.exp test is a bit buggy
(stuff for another patch...), in that it calls gdb_load (through
clean_restart) with a file that doesn't exist. The gdb_load
implementation in simavr.exp gets called with a file that doesn't exist,
and simavr (expectedly) fails to start.
When this happens, we currently leave the $simavr_spawn_id variable set.
However, because the simavr process has terminated, its spawn id is
closed. When the next test tries to close the previous connection to
simavr, it fails to, and this error is thrown:
ERROR: close: spawn id exp86 not open
while executing
"close -i $simavr_spawn_id"
(procedure "gdb_load" line 18)
invoked from within
In other words, any test ran after step-over-syscall.exp will have
simavr.exp's gdb_load fail on it.
This patch tries to make sure that simavr.exp's gdb_load only leaves
simavr_spawn_id set if everything went fine. If we couldn't start
simavr, don't see the expected output, or fail to connect to it, we
close the spawn id (if needed) and unset simavr_spawn_id.
As an additional precaution, I added a catch around the "close the
previous connection" code. Ideally, this shouldn't be necessary, but I
bet there are other similar scenarios where we might try to close an
already close spawn id. So I think displaying a warning is better than
messing up all following tests.
Also, the board never wait'ed for the simavr process, resulting in tons
of zombie simavr processes hanging around. This patch adds some calls
to "wait" whenever we close the connection (or realize it is already
closed), which seems to fix the problem.
Finally I switched a `gdb_expect` to bare `expect`, where we wait for
the "listening" message from simavr. I found it necessary because
gdb_expect (through remote_expect) adds a `-i <gdb spawn id> -timeout
10`. So if for some reason the GDB process has crashed in the mean
time, this expect will unexpectedly error out with a `spawn id <gdb
spawn id> not open`. Therefore, change `gdb_expect` to `expect` so that
we only deal with simavr's spawn id here.
Here are the results on TESTS="gdb.base/*.exp" before:
# of expected passes 4816
# of unexpected failures 4433
# of known failures 2
# of unresolved testcases 300
# of untested testcases 143
# of unsupported tests 7
# of paths in test names 2
# of duplicate test names 10
and after:
# of expected passes 21957
# of unexpected failures 1564
# of expected failures 8
# of unknown successes 1
# of known failures 31
# of unresolved testcases 532
# of untested testcases 153
# of unsupported tests 28
# of paths in test names 2
# of duplicate test names 32
I tested using simavr's current master (7c254e2081b5).
gdb/testsuite/ChangeLog:
* boards/simavr.exp (gdb_load): Catch errors when closing
previous connection. Close connection, wait for process and
unset simavr_spawn_id on failure.
Change-Id: I695fc765e1c22e1d1dc0b08e0f5141244986b868
|
|
Add new target board that uses gold to add a .gdb_index section, enabled by
-ggnu-pubnames.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-25 Tom de Vries <tdevries@suse.de>
* boards/gold-gdb-index.exp: New file.
|
|
This patch adds a board file for against a simavr target (so, for the
AVR architecture).
simavr, when started with option -g, runs a GDB stub on port 1234. In
the current latest release (1.6), the port is hardcoded to 1234. But in
master, there is the option to choose another port. So while the board
file hardcodes the port today, in the future it should be possible to
let the user choose a port, or automatically select a free port.
It is easy enough to run, make sure you have avr-gcc/avr-g++ and simavr
installed, and as usual just run:
make check RUNTESTFLAGS="--target_board=simavr"
The following environment variables influence the behavior of the board
file:
- SIMAVR_MCU: type of chip to simulate
- SIMAVR_PATH: path to simavr binary (useful if you build your own
simavr or for some reason it is not simply called `simavr`.
As expected, there are a lot of failures. Many tests use some features
not supported by such a target, and I suppose there are real GDB bugs
too. But a lot also passes (including tests that actually run stuff),
so this board file should still help to validate changes to the AVR
architecture support.
These are the results I got of running tests gdb.base/*.exp:
# of expected passes 20926
# of unexpected failures 2257
# of expected failures 14
# of unknown successes 1
# of known failures 13
# of unresolved testcases 592
# of untested testcases 156
# of unsupported tests 30
# of paths in test names 3
# of duplicate test names 56
gdb/testsuite/ChangeLog:
* boards/simavr.exp: New file.
Change-Id: Ib7fa8c4e2e90b08b104bb9b552df37779de3bc21
|
|
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 a target board that uses the gold linker.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-25 Tom de Vries <tdevries@suse.de>
* boards/gold.exp: New file.
|
|
This patch adds a target board debug-types that switches on
-fdebug-types-section by default.
This -fdebug-types-section option is a gcc option that enables the generation
of a .debug_types section, which is only effective for DWARF version 4.
There are two other boards that enable this: dwarf4-gdb-index and fisson, but
while those test some meaningful combination of options, this board is
intended to test only -fdebug-types-section.
Current results with gcc 7.5.0 are:
...
=== gdb Summary ===
# of expected passes 75832
# of unexpected failures 2841
# of expected failures 130
# of known failures 75
# of unresolved testcases 22
# of untested testcases 37
# of unsupported tests 83
...
Related known issues:
- PR gcc/90232 - "gcc drops top-level dies with -fdebug-types-section"
- PR gdb/25875 - "segv in ada_discrete_type_low_bound"
- PR gdb/14148 - "-fdebug-types-section regresses static scope of types"
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-04-25 Tom de Vries <tdevries@suse.de>
* boards/debug-types.exp: New file.
|
|
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.
|
|
This updates the gdb testsuite to look for gdbserver in its new
location. The old location is also checked for, on the theory that
perhaps someone sets GDB to a full path for install testing.
gdb/testsuite/ChangeLog
2020-02-14 Tom Tromey <tom@tromey.com>
* lib/gdbserver-support.exp (find_gdbserver): Find gdbserver in
build directory.
* boards/gdbserver-base.exp: Update path to gdbserver.
Change-Id: If03db762ba53882ddfaf2d2d516de14c3fa03938
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
The board file cc-with-tweaks is used as the core for lots of other
board files, for example cc-with-gdb-index and cc-with-debug-names.
This commit extends cc-with-tweaks so that it will wrap the Fortran
compiler, allowing for more test coverage.
I tested all of the board files that make use of cc-with-tweaks
running the gdb.fortran/*.exp test set, and in some cases I did see
extra failures. The "standard" results are:
=== gdb Summary ===
# of expected passes 953
# of known failures 2
With board file 'cc-with-dwz-m':
=== gdb Summary ===
# of expected passes 903
# of unexpected failures 1
# of known failures 2
# of untested testcases 4
With board file 'dwarf4-gdb-index':
=== gdb Summary ===
# of expected passes 950
# of unexpected failures 3
# of known failures 2
With board file 'fission-dwp':
=== gdb Summary ===
# of expected passes 949
# of unexpected failures 4
# of known failures 2
Despite these extra failure I don't think this should prevent this
change going in as these failures presumably already exist in GDB.
gdb/testsuite/ChangeLog:
* boards/cc-with-tweaks.exp: Setup F90_FOR_TARGET and
F77_FOR_TARGET.
Change-Id: I06d412f94d0e119ad652dd6c20829f6705a54622
|
|
This adds Ada support to the cc-with-tweaks.exp board file, so that we
can test Ada this way. The cc-with-tweaks.sh script already works
reasonably well as a wrapper for gnatmake.
gdb/testsuite/ChangeLog
2019-09-10 Tom Tromey <tromey@adacore.com>
* boards/cc-with-tweaks.exp: Set GNATMAKE_FOR_TARGET.
|
|
The target board fission.exp requires the gold linker (because it supports
--gdb-index).
When running the target board on a system where the default linker is not
gold, most tests will fail to compile.
Fix this by adding "-fuse-ld=gold" ( supported in gcc since version 4.8).
gdb/testsuite/ChangeLog:
2019-06-18 Tom de Vries <tdevries@suse.de>
* boards/fission.exp (debug_flags): Add "-fuse-ld=gold".
|
|
gdb/testsuite/ChangeLog:
2019-06-18 Tom de Vries <tdevries@suse.de>
* boards/fission.exp: Break up long debug_flags line.
|
|
Add a target board to test -readnow.
gdb/testsuite/ChangeLog:
2019-06-11 Tom de Vries <tdevries@suse.de>
* boards/readnow.exp: New file.
|
|
Add a target board that makes it easy to run the test suite with a
.debug_names section added to executables.
gdb/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh: Support -n arg.
gdb/testsuite/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* boards/cc-with-debug-names.exp: New file.
|
|
Add a target board cc-with-gdb-index.exp, to make it easy to run cc-with-tweaks
with CC_WITH_TWEAKS_FLAGS='-i'.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-03 Tom de Vries <tdevries@suse.de>
* boards/cc-with-gdb-index.exp: New file.
|
|
When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run
into:
...
$ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp"
Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ...
gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb
=== gdb Summary ===
nr of untested testcases 1
...
The same happens with fullname.exp.
The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses
cc-with-tweaks.sh, which calls gdb-add-index.sh.
The gdb-add-index.sh script uses a gdb executable, defaulting to gdb:
...
GDB=${GDB:=gdb}
...
The cc-with-tweaks.sh script tries to ensure that the build gdb executable is
used by gdb-add-index.sh:
...
if [ -z "$GDB" ]
then
if [ -f ./gdb ]
then
GDB="./gdb -data-directory data-directory"
elif [ -f ../gdb ]
then
GDB="../gdb -data-directory ../data-directory"
elif [ -f ../../gdb ]
then
GDB="../../gdb -data-directory ../../data-directory"
else
echo "$myname: unable to find usable gdb" >&2
exit 1
fi
fi
...
So, if the current directory is build/gdb/testsuite, then a gdb executable
build/gdb/testsuite/../gdb will be used.
However, in the case of fullpath-expand.exp the test cd's into the sources:
...
set saved_pwd [pwd]
cd $srcdir
set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \
executable {debug}]
cd $saved_pwd
...
and cc-with-tweaks.sh generates the "unable to find usable gdb" error.
The same error occurs if we use --target_board=cc-with-dwz instead (only in
this case we actually don't need gdb, we just need the GDB variable to be set
in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh).
Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using
$GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to
cc-with-tweaks.sh by setting env(GDB).
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).
|
|
Board file dwarf4-gdb-index.exp contains all the commands from
cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i").
Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp.
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.
|
|
When running break-probes.exp with native-gdbserver, we run into:
...
FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
FAIL: gdb.base/break-probes.exp: call (int) foo(23)
...
due to the fact that we're trying to match:
...
Inferior loaded /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
using pattern:
...
Inferior loaded $sysroot$binfile_lib
...
which expands into:
...
Inferior loaded //data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base\
/break-probes/break-probes-solib.so
...
Fix by setting sysroot to "" in local-board.exp.
Tested on x86_64-linux with native-gdbserver.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
PR gdb/24433
* boards/local-board.exp: Set sysroot to "".
|
|
We can use CC_WITH_TWEAKS_FLAGS when cd-ing into the gdb build subdir and
invoking make check:
...
$ cd $objdir/gdb
$ make check \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
But when cd-ing into the top-level build dir and invoking make check-gdb
instead:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-tweaks' \
CC_WITH_TWEAKS_FLAGS='-z'
...
using CC_WITH_TWEAKS_FLAGS has no effect, because CC_WITH_TWEAKS_FLAGS is not
passed down from the top level Makefile.
Add cc-with-dwz.exp and cc-with-dwz-m.exp, that don't require
CC_WITH_TWEAKS_FLAGS to be set in the make invocation, allowing us to run these
test configurations from the toplevel build dir:
...
$ cd $objdir
$ make check-gdb \
RUNTESTFLAGS='--target_board=cc-with-dwz'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-11 Tom de Vries <tdevries@suse.de>
* boards/cc-with-dwz-m.exp: New file.
* boards/cc-with-dwz.exp: New file.
* boards/cc-with-tweaks.exp: Note that check-gdb doesn't work.
|
|
When testing using native-gdbserver and native-extended-gdbserver, the sysroot
is not set. This results in a warning from GDB and files are sent via the
remote protocol, which can be slow.
On Ubuntu 18.04 (unlike most distros) the debug versions of the standard
libraries are included by default in /usr/lib/debug/.
These file reads are causing a complete native-gdbserver run on the AArch64
buildbot slave to timeout after 2.5 hours. This is also causing the builds
to back up on the slave.
The solution is to ensure the sysroot is set to / for all local boards.
This drastically reduces the time of a test. For example, gdb.base/sigall.exp
drops from 23 seconds to 4 seconds.
A full native-gdbserver run on the AArch64 slave now takes 8 minutes.
gdb/testsuite/ChangeLog:
* boards/local-board.exp: set sysroot to /.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
This patch implements IPv6 support for both GDB and gdbserver. Based
on my research, it is the fourth attempt to do that since 2006. Since
I used ideas from all of the previous patches, I also added their
authors's names on the ChangeLogs as a way to recognize their
efforts. For reference sake, you can find the previous attempts at:
https://sourceware.org/ml/gdb-patches/2006-09/msg00192.html
https://sourceware.org/ml/gdb-patches/2014-02/msg00248.html
https://sourceware.org/ml/gdb-patches/2016-02/msg00226.html
The basic idea behind the patch is to start using the new
'getaddrinfo'/'getnameinfo' calls, which are responsible for
translating names and addresses in a protocol-independent way. This
means that if we ever have a new version of the IP protocol, we won't
need to change the code again (or, at least, won't have to change the
majority of the code).
The function 'getaddrinfo' returns a linked list of possible addresses
to connect to. Dealing with multiple addresses proved to be a hard
task with the current TCP auto-retry mechanism implemented on
ser-tcp:net_open. For example, when gdbserver listened only on an
IPv4 socket:
$ ./gdbserver --once 127.0.0.1:1234 ./a.out
and GDB was instructed to try to connect to both IPv6 and IPv4
sockets:
$ ./gdb -ex 'target extended-remote localhost:1234' ./a.out
the user would notice a somewhat big delay before GDB was able to
connect to the IPv4 socket. This happened because GDB was trying to
connect to the IPv6 socket first, and had to wait until the connection
timed out before it tried to connect to the IPv4 socket.
For that reason, I had to rewrite the main loop and implement a new
method for handling multiple connections. After some discussion,
Pedro and I agreed on the following algorithm:
1) For each entry returned by 'getaddrinfo', we try to open a socket
and connect to it.
2.a) If we have a successful 'connect', we just use that connection.
2.b) If we don't have a successfull 'connect', but if we've got a
ECONNREFUSED (meaning the the connection was refused), we keep track
of this fact by using a flag.
2.c) If we don't have a successfull 'connect', but if we've got a
EINPROGRESS (meaning that the connection is in progress), we perform
a 'select' call on the socket until we have a result (either a
successful connection, or an error on the socket).
3) If tcp_auto_retry is true, and we haven't gotten a successful
connection, and at least one of our attempts failed with
ECONNREFUSED, then we wait a little bit (i.e., call
'wait_for_connect'), check to see if there was a
timeout/interruption (in which case we bail out), and then go back
to (1).
After multiple tests, I was able to connect without delay on the
scenario described above, and was also able to connect in all other
types of scenarios.
I also implemented some hostname parsing functions (along with their
corresponding unit tests) which are used to help GDB and gdbserver to
parse hostname strings provided by the user. These new functions are
living inside common/netstuff.[ch]. I've had to do that since IPv6
introduces a new URL scheme, which defines that square brackets can be
used to enclose the host part and differentiate it from the
port (e.g., "[::1]:1234" means "host ::1, port 1234"). I spent some
time thinking about a reasonable way to interpret what the user wants,
and I came up with the following:
- If the user has provided a prefix that doesn't specify the protocol
version (i.e., "tcp:" or "udp:"), or if the user has not provided
any prefix, don't make any assumptions (i.e., assume AF_UNSPEC when
dealing with 'getaddrinfo') *unless* the host starts with "[" (in
which case, assume it's an IPv6 host).
- If the user has provided a prefix that does specify the protocol
version (i.e., "tcp4:", "tcp6:", "udp4:" or "udp6:"), then respect
that.
This method doesn't follow strictly what RFC 2732 proposes (that
literal IPv6 addresses should be provided enclosed in "[" and "]")
because IPv6 addresses still can be provided without square brackets
in our case, but since we have prefixes to specify protocol versions I
think this is not an issue.
Another thing worth mentioning is the new 'GDB_TEST_SOCKETHOST'
testcase parameter, which makes it possible to specify the
hostname (without the port) to be used when testing GDB and
gdbserver. For example, to run IPv6 tests:
$ make check-gdb RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp6:[::1]'
Or, to run IPv4 tests:
$ make check-gdb RUNTESTFLAGS='GDB_TEST_SOCKETHOST=tcp4:127.0.0.1'
This required a few changes on the gdbserver-base.exp, and also a
minimal adjustment on gdb.server/run-without-local-binary.exp.
Finally, I've implemented a new testcase,
gdb.server/server-connect.exp, which is supposed to run on the native
host and perform various "smoke tests" using different connection
methods.
This patch has been regression-tested on BuildBot and locally, and
also built using a x86_64-w64-mingw32 GCC, and no problems were found.
gdb/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
'unittests/parse-connection-spec-selftests.c'.
(COMMON_SFILES): Add 'common/netstuff.c'.
(HFILES_NO_SRCDIR): Add 'common/netstuff.h'.
* NEWS (Changes since GDB 8.2): Mention IPv6 support.
* common/netstuff.c: New file.
* common/netstuff.h: New file.
* ser-tcp.c: Include 'netstuff.h' and 'wspiapi.h'.
(wait_for_connect): Update comment. New parameter
'gdb::optional<int> sock' instead of 'struct serial *scb'.
Use 'sock' directly instead of 'scb->fd'.
(try_connect): New function, with code from 'net_open'.
(net_open): Rewrite main loop to deal with multiple
sockets/addresses. Handle IPv6-style hostnames; implement
support for IPv6 connections.
* unittests/parse-connection-spec-selftests.c: New file.
gdb/gdbserver/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* Makefile.in (SFILES): Add '$(srcdir)/common/netstuff.c'.
(OBS): Add 'common/netstuff.o'.
(GDBREPLAY_OBS): Likewise.
* gdbreplay.c: Include 'wspiapi.h' and 'netstuff.h'.
(remote_open): Implement support for IPv6
connections.
* remote-utils.c: Include 'netstuff.h', 'filestuff.h'
and 'wspiapi.h'.
(handle_accept_event): Accept connections from IPv6 sources.
(remote_prepare): Handle IPv6-style hostnames; implement
support for IPv6 connections.
(remote_open): Implement support for printing connections from
IPv6 sources.
gdb/testsuite/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* README (Testsuite Parameters): Mention new 'GDB_TEST_SOCKETHOST'
parameter.
* boards/native-extended-gdbserver.exp: Do not set 'sockethost'
by default.
* boards/native-gdbserver.exp: Likewise.
* gdb.server/run-without-local-binary.exp: Improve regexp used
for detecting when a remote debugging connection succeeds.
* gdb.server/server-connect.exp: New file.
* lib/gdbserver-support.exp (gdbserver_default_get_comm_port):
Do not prefix the port number with ":".
(gdbserver_start): New global GDB_TEST_SOCKETHOST. Implement
support for detecting and using it. Add '$debughost_gdbserver'
to the list of arguments used to start gdbserver. Handle case
when gdbserver cannot resolve a network name.
gdb/doc/ChangeLog:
2018-07-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
Paul Fertser <fercerpav@gmail.com>
Tsutomu Seki <sekiriki@gmail.com>
* gdb.texinfo (Remote Connection Commands): Add explanation
about new IPv6 support. Add new connection prefixes.
|
|
The cc-with-tweaks.sh script needs to be executed with bash. When
trying to run this:
make check RUNTESTFLAGS="--target_board=dwarf4-gdb-index" TESTS="gdb.base/return.exp"
I get:
gdb compile failed, /home/emaisin/src/binutils-gdb/gdb/contrib/cc-with-tweaks.sh: 174: /home/emaisin/src/binutils-gdb/gdb/contrib/cc-with-tweaks.sh: Bad substitution
The reason is that the board files execute cc-with-tweaks.sh using
/bin/sh, which points to dash on my machine. Remove the /bin/sh part
and let the shebang choose the right interpreter.
gdb/testsuite/ChangeLog:
* boards/cc-with-tweaks.exp: Don't call cc-with-tweaks.sh
through /bin/sh.
* boards/dwarf4-gdb-index.exp: Likewise.
* boards/fission-dwp.exp: Likewise.
|
|
As described here
https://sourceware.org/bugzilla/show_bug.cgi?id=22841
there seems to be situations where the remote-stdio-gdbserver board
fails to delete the uploaded binary file. Passing "target" fixes the
issue for Christian who reported the bug.
I did not experience this problem, but passing "target" to remote_exec
still works for me, so I'm fine with changing it.
Any objection?
gdb/testsuite/ChangeLog:
PR gdb/22841
* boards/remote-stdio-gdbserver.exp (${board}_file): Pass
"target" to remote_exec.
|
|
Before patch
Make native gdbserver boards no longer be "remote" (in DejaGnu terms)
739b3f1d8ff7072dcc66240c25b026c6433bda1a
the local gdbserver boards (except native-extended-gdbserver...) were
considered as remote by DejaGNU. To avoid DejaGNU trying to use ssh/scp
to download the files to the target (which is actually local), the
gdbserver-base.exp file defined some _download, _upload and _file board
operations to override the default behavior, and instead just use local
operations.
The same patch also changed remote-stdio-gdbserver.exp to make it
inherit from gdbserver-base.exp. Since then, this board (which is
actually remote) uses the overrides with local file operations. As a
result, files are never actually copied to the target.
I think we can simply remove the overrides from gdbserver-base.exp.
Because all boards should be properly considered local or remote by
DejaGNU, it should by default use the right method for transferring
files.
gdb/testsuite/ChangeLog:
PR gdb/22841
* boards/gdbserver-base.exp (${board}_file, ${board}_download,
${board}_upload): Remove.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files
|
|
local-board.exp was introduced recently, containing the code required to
force the gdbserver boards to be non-remote (from the DejaGNU point of
view). Other board files use the same trick of forcing isremote to 0.
Instead of doing it by hand in each file, include local-board.exp.
gdb/testsuite/ChangeLog:
* boards/cc-with-tweaks.exp: Include local-board.exp instead of
setting isremote by hand.
* boards/dwarf4-gdb-index.exp: Likewise.
* boards/fission.exp: Likewise.
* boards/stabs.exp: Likewise.
|
|
I've noticed now that due to a last-minute change, commit 739b3f1d8ff7
("Make native gdbserver boards no longer be "remote" (in DejaGnu
terms)") managed to miss loading "local-board" in the
native-stdio-gdbserver board...
gdb/testsuite/ChangeLog:
2017-10-17 Pedro Alves <palves@redhat.com>
* boards/native-stdio-gdbserver.exp: Load "local-board".
|
