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.
On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...
The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
# If GDB is lack of XML support, and targets, like arm, have
# multiple target descriptions, GDB doesn't know which target
# description GDBserver uses, and may fail to parse 'g' packet
# after connection.
if { [gdb_skip_xml_test]
&& ([istarget "arm*-*-linux*"]
|| [istarget "mips*-*-linux*"]
|| [istarget "powerpc*-*-linux*"]
|| [istarget "s390*-*-linux*"]
|| [istarget "x86_64-*-linux*"]
|| [istarget "i\[34567\]86-*-linux*"]) } {
return 1
}
...
but it doesn't trigger because aarch64 is missing.
Fix this by adding istarget "aarch64*-*-linux*".
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...
The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails. The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.
Fix this by checking the result of the call to bfd_get_section_contents.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29652
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.
We're currently seeing testing of native-extended-gdbserver hang while
testing the x86_64 architecture on both Fedora 34 and Fedora Rawhide.
The test responsible for the hang is gdb.threads/fork-plus-threads.exp.
While there is clearly a problem/bug with this test on F34 and
Rawhide, it's also the case that testing should not hang. This commit
prevents the hang by waiting with the "-nowait" flag in
close_gdbserver.
The -nowait flag is also used in the kill_wait_spawned_process proc in
gdb/testsuite/lib/gdb.exp, so there is precedent for doing this.
There are also 15 other uses of "wait -i" scattered throughout the
test suite. While it's tempting to change these to also use the
-nowait flag, I think it might be safer to defer doing so until we
actually see a problem.
I've tested this patch on Fedora 32, 33, 34, and Rawhide. Results are
comparable on Fedora 32 and 33. On Fedora 34 and Rawhide, with this
commit in place, testing completes when the target_board is
native-extended-gdbserver. On those OSes, when not using this commit,
testing usually hangs due to a problem with
gdb.threads/fork-plus-threads.exp. I've also tested on all of the
mentioned OSes with target_board=native-gdbserver; for that testing,
I achieved comparable results over a number of runs. (Unfortunately
results are rarely identical due to racy tests.)
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_exit): Use the
"-nowait" flag when waiting for gdbserver to exit.
On Ubuntu 18.04/20.04 I was running into annoying timeouts for
gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because
they were running into the "Cannot assign requested address" error, originated
from the connect syscall.
Improve this by handling this additional error in the testsuite library.
It still fails for me, but at least it fails pretty quickly and doesn't make the
testsuite run take longer.
gdb/testsuite/ChangeLog:
2021-01-21 Luis Machado <luis.machado@linaro.org>
* lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error
message.
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.
With this gdbserver-support.exp patch:
...
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise,
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set have_prompt 0
expect {
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
+ set have_prompt 1
exp_continue
}
-i "$server_spawn_id" eof {
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
warning "Timed out waiting for EOF in server after $monitor_exit"
}
}
+ gdb_assert {$have_prompt}
}
}
close_gdbserver
...
and with this in parallel:
...
$ stress -c 5
...
we run into this and similar FAILs:
...
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
...
In more detail:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
Remote debugging from host ::1, port 40712^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target \
created; pid = 11098^M
monitor exit^M
Killing process(es): 11098^M
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
spawn build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory \
build/gdb/testsuite/../data-directory^M
...
After issuing a "monitor exit" command, we should always get a prompt back, so
check for that.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-16 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdbserver_exit): Make sure we
get the gdb prompt after issuing "monitor exit".
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.
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
This adds a testcase exercising multi-target features. It spawns 6
inferiors, like this:
inferior 1 -> native
inferior 2 -> extended-remote 1
inferior 3 -> core
inferior 4 -> native
inferior 5 -> extended-remote 2
inferior 6 -> core
and then tests various details, including:
- running to breakpoints
- interrupting with Ctrl-C and "interrupt -a"
- "next" bouncing between two breakpoints in two threads running in
different targets.
- since we have cores and live inferiors mixed in the same session,
this makes sure that gdb doesn't try to remove a core dump's
threads.
- all-stop and non-stop modes.
This testcase caught a _lot_ of bugs in development.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-target.c: New file.
* gdb.multi/multi-target.exp: New file.
* lib/gdbserver-support.exp (gdb_target_cmd): Handle "Non-stop
mode requested, but remote does not support non-stop".
In commit 81dc3ab594 "[gdb/testsuite] Handle unreachable network in
server-connect.exp" a regression was introduced in gdb_target_cmd, causing
ERRORs like this:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.server/abspath.exp.
ERROR: wrong # args: should be "gdb_target_cmd {$args}"
while executing
"gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport"
...
Fix the argument passing in gdb_target_cmd.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd): Fix argument passing.
When running gdb.server/server-connect.exp I run into:
...
FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
FAIL: gdb.server/server-connect.exp: tcp6-with-brackets: connect to gdbserver \
using tcp6:[::1]
FAIL: gdb.server/server-connect.exp: udp6: connect to gdbserver using udp6:::1
FAIL: gdb.server/server-connect.exp: udp6-with-brackets: connect to gdbserver \
using udp6:[::1]
...
The FAIL is caused by the fact that the ipv6 loopback address is not available:
...
PASS: gdb.server/server-connect.exp: tcp6: start gdbserver
target remote tcp6:::1:2347^M
A program is being debugged already. Kill it? (y or n) y^M
tcp6:::1:2347: Network is unreachable.^M
(gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1
...
This should be marked UNSUPPORTED rather than FAIL.
Furthermore, the test-case takes about 4 minutes, because the 'Network is
unreachable' response is not explicitly handled in gdb_target_cmd, so instead
it runs into the timeout case.
Fix this by handling the 'Network is unreachable' response as UNSUPPORTED.
This reduces testing time from 4 minutes to about 2 seconds.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-09-19 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdb_target_cmd_ext): Return 2 (meaning
UNSUPPORTED) for 'Network is unreachable' message. Factor out of ...
(gdb_target_cmd): ... here.
* gdb.server/server-connect.exp: Use gdb_target_cmd_ext, handle return
value 2.
This matches the kill in gdb_file_cmd, and ensures that the command is not
sent to the gdb.in file.
When gdb.in is used as a batch file, any kill commands run before the target
is started will cause gdb to stop processing commands.
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_run): Mark kill as optional.
Add "replay" to the list of GDBSERVER_DEBUG options. This will
cause a gdbserver.replay file to be written to the test output
directory.
At the same time switch this to a comma separated list in order
to easily handle all possible options.
The replay log is created by GDB, but has been added to
GDBSERVER_DEBUG as it is only required for gdbserver tests. To
enable it, the gdb_debug_init is overridden to allow the additional
checking, before calling the original function.
gdb/testsuite/ChangeLog:
* README (Testsuite Parameters): Add replay logging to
GDBSERVER_DEBUG.
(gdbserver,debug): Refer to GDBSERVER_DEBUG.
* lib/gdbserver-support.exp (gdbserver_start): Treat gdbserverdebug
as a comma separated list.
(gdb_debug_init): Override procedure.
When spawning gdb or gdbserver create a .cmd file in the test output
directory containing the full command line, ensuring the current gdb
instance is appended to the files so that they can be quickly matched
to the corresponding gdb.in file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_spawn): Call gdb_write_cmd_file.
(gdb_write_cmd_file): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Call
gdbserver_write_cmd_file.
(gdbserver_write_cmd_file): New proedure.
Add both board option and environment variable which enables gdbserver
debug and sends it to the file gdbserver.debug, located in the output
directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdbserver debug enabled in the following way:
make check GDBSERVER_DEBUG=all
Disable tspeed.exp when debugging to prevent the log file filling
many gigabytes then timing out.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDBSERVER_DEBUG.
* README (Testsuite Parameters): Add GDBSERVER_DEBUG.
(gdbserver,debug): Add board setting.
* gdb.trace/tspeed.exp: Skip when debugging.
* lib/gdb.exp (gdbserver_debug_enabled): New procedure.
* lib/gdbserver-support.exp: Likewise
The local board file ensures that the sysroot is always set to load
files from the local filesystem.
Add a gdbserver test to explicitly test the sysroot set to both the
remote target and the local filesystem.
gdb/testsuite/ChangeLog:
* gdb.server/sysroot.c: New test.
* gdb.server/sysroot.exp: New file.
* lib/gdbserver-support.exp (gdb_target_cmd): Add additional text
matching param.
When launching gdbserver, the testsuite checks for binding failure but
does not check for failure to listen to socket error (which can happen
due to another gdbserver binding to the socket at the same time).
When this error occurs, the test will ignore the error and connect GDB
to the failed port. This may succeed and GDB will now be connected to
the gdbserver from another test. This eventually causes both tests to
fail.
When running the tests suite with native-gdbserver across many cores,
this issue may happen once or twice, each causing random failures for
two .exp testscripts.
Example gdb.log output for the failure:
The testsuite sucessfully notices a failure to connect to port 2348.
It launches again with port 2349, which also fails. The testsuite
ignores this error and uses gdb to connect to the port - which succeeds.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M
Can't bind address: Address already in use.^M
Exiting^M
Port 2348 is already in use.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M
Can't listen on socket: Address already in use.^M
Exiting^M
target remote localhost:2349^M
Remote debugging using localhost:2349^M
Reading /lib/ld-linux-aarch64.so.1 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-aarch64.so.1 from remote target...^M
Reading symbols from target:/lib/ld-linux-aarch64.so.1...^M
Reading /lib/ld-2.23.so from remote target...^M
Reading /lib/.debug/ld-2.23.so from remote target...^M
Reading /work/build/install/lib/debug//lib/ld-2.23.so from remote target...^M
Reading /work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M
Reading target:/work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M
(No debugging symbols found in target:/lib/ld-linux-aarch64.so.1)^M
0x0000ffffbf6d2cc0 in ?? () from target:/lib/ld-linux-aarch64.so.1^M
(gdb) continue^M
Continuing.^M
Reading /lib/aarch64-linux-gnu/libc.so.6 from remote target...^M
Reading /lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M
Reading /lib/aarch64-linux-gnu/.debug/libc-2.23.so from remote target...^M
Reading /work/build/install/lib/debug//lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M
Reading /work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M
Reading target:/work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M
[Inferior 1 (process 35351) exited normally]^M
(gdb) FAIL: gdb.ada/arrayidx.exp: can't run to main
Meanwhile, at the same time, in another test, gdbserver successfully
connects to port 2349. GDB then tries to connect to the port, but it
times out because the GDB in the test above has already connected to it.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M
Can't bind address: Address already in use.^M
Exiting^M
Port 2348 is already in use.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M
Process /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo created; pid = 65162^M
Listening on port 2349^M
Remote debugging from host 127.0.0.1, port 45154^M
target remote localhost:2349^M
localhost:2349: Connection timed out.^M
(gdb) ^CQuit^M
(gdb) task 2^M
Cannot inspect Ada tasks when program is not running^M
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_start): Check for listen
failure.
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.
On commit:
commit 7f1f7e23939adc7d71036a17fc6081e3af7ca585
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date: Fri Jul 13 16:20:34 2018 -0400
Expect for another variant of error message when gdbserver cannot resolve hostname
I extended the regular expression being used to identify whether
gdbserver could not resolve a (host)name. This was needed because the
error message being printed had a different variation across some
systems. However, as it turns out, I've just noticed that the message
has yet another variation:
target remote tcp8:123:2353
tcp8:123:2353: cannot resolve name: System error
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
tcp8:123:2353: No such file or directory.
(gdb) FAIL: gdb.server/server-connect.exp: tcp8: connect to gdbserver using tcp8:123
which is causing FAILs on some systems (namely, Fedora-i686 on
BuildBot).
So instead of trying to predict everything that can be printed, I
decided to just match anything after the "cannot resolve name: " part.
This patch implements that.
Regression tested on the BuildBot.
gdb/testsuite/ChangeLog:
2018-07-30 Sergio Durigan Junior <sergiodj@redhat.com>
* lib/gdbserver-support.exp (gdbserver_start): Match any kind of
error after "cannot resolve name" string.
I've noticed that on a few hosts, when given an invalid hostname,
gdbserver fails with:
spawn /../../gdb/gdbserver/gdbserver --once tcp8:123:2353 /gdb/build/fedora-s390x/build/gdb/testsuite/outputs/gdb.server/server-connect/server-connect
tcp8:123:2353: cannot resolve name: No address associated with hostname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exiting
Unfortunately, this causes a fail on the new
gdb.server/server-connect.exp test (introduced by the IPv6 patch):
FAIL: gdb.server/server-connect.exp: tcp8: start gdbserver: gdbserver should fail but did not
This happens because we're expecting for another variant of this error
message:
cannot resolve name: Name or service not known
Therefore, this patch extends the helper function 'gdbserver_start' to
also recognize the "No address associated with hostname" message.
This "fixes" the testcase on the hosts that use this variant.
gdb/testsuite/ChangeLog:
2018-07-13 Sergio Durigan Junior <sergiodj@redhat.com>
* lib/gdbserver-support.exp (gdbserver_start): Expect for the
message "No address associated with hostname" when gdbserver
cannot resolve the hostname.
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.htmlhttps://sourceware.org/ml/gdb-patches/2014-02/msg00248.htmlhttps://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.
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
In commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver), we override gdb_exit in lib/gdbserver-support.exp, so
that we can close gdbserver first. However, we don't close gdbserver
in mi_gdb_exit. This makes a problem in my aarch64 mulit-arch testing,
in which I run some mi tests, mi-watch.exp for example, in different
variations (aarch64 and arm),
Schedule of variations:
junor0-2
junor0-2-arm/-marm
junor0-2-arm/-mthumb
When the test is done in the first variation (aarch64), test case is
recompiled for arm, but GDBserver with aarch64 program is still
running. When the second variation is started, GDB loads arm program,
but GDBserver still loads aarch64 program because the old GDBserver
process is using it. We'll get,
47-target-select remote junor0-2:2350^M
&"warning: Selected architecture arm is not compatible with reported target architecture aarch64\n"^M
&"warning: Architecture rejected target-supplied description\n"
This patch fixes this problem by closing GDBserver in mi_gdb_exit.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Rename mi_gdb_exit.
(gdb_exit): Rename it to ...
(gdbserver_gdb_exit): ... Close GDBserver.
(gdb_exit): New proc, call gdbserver_gdb_exit.
(mi_gdb_exit): Likewise.
In lib/gdbserver-support.exp, we rename gdb_exit to
gdbserver_orig_gdb_exit, but we check the existence gdbserver_gdb_exit.
We should check gdbserver_orig_gdb_exit instead. Looks it is a typo
or an oversight.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Check the existence of
gdbserver_orig_gdb_exit rather than gdbserver_gdb_exit.
I recently see some gdb.server/*.exp fails in my native gdb testing,
in which libexpat isn't available, so GDB isn't able to parse xml file.
It causes gdb.server/ tests fails because GDB can't get registers
correctly from GDBserver.
(gdb) PASS: gdb.server/connect-without-multi-process.exp: multiprocess=off: break main
target remote localhost:2352^M
Remote debugging using localhost:2352^M
warning: Can not parse XML target description; XML support was disabled at compile time^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.17.so.debug from remote target...^M
Reading /lib/.debug/ld-2.17.so.debug from remote target...^M
(no debugging symbols found)...done.^M
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efffbe00000000808d0f4d100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000^
0x4d0f8d80 in _start () from target:/lib/ld-linux-armhf.so.3^M
Without XML support in GDB, it can't parse xml sent by GDBserver, and has
to fall back to the oldest arch. However, GDBserver doesn't know this
(IMO, this is a defect in RSP), and still choose the right target
description to create regcache and 'g' packet. If the port only has
one target description or coincidentally two sides choose the same
target description, there is no such issue. Otherwise, GDB is broken
on read registers.
This patch is to skip gdbserver tests if XML is not support and the
target has multiple target descriptions.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (skip_gdbserver_tests): Return 1
if gdb_skip_xml_test is true on some targets.
Commit 51f77c3704a6 ("Add testing infrastruture bits for running with
MI on a separate UI") broke MI testing with native-gdbserver:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver mi-var-child.exp"
...
Running .../src/binutils-gdb/gdb/testsuite/gdb.mi/mi-var-child.exp ...
can't unset "inferior_spawn_id": no such variable
while executing
"unset inferior_spawn_id"
(procedure "close_gdbserver" line 20)
invoked from within
"close_gdbserver"
...
When testing with gdbserver, gdb_exit is overridden with a special
version that calls close_gdbserver, which clears inferior_spawn_id.
The problem is that the commit mentioned above made
gdb_exit/mi_gdb_exit clear inferior_spawn_id too, and clearing a
non-existing variable is a tcl error.
Since gdb_exit/mi_gdb_exit always clears inferior_spawn_id now, the
fix is simply to stop clearing it in close_gdbserver.
gdb/testsuite/
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (close_gdbserver, gdb_exit): Don't
unset inferior_spawn_id.
Commit 7817ea46148d (Improve gdb_remote_download, remove gdb_download)
caused:
FAIL: gdb.server/solib-list.exp: non-stop 0: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: target extended-remote (timeout)
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program is no longer running)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
gdb.log shows:
system interpreter is: /lib64/ld-linux-x86-64.so.2
...
spawn ../gdbserver/gdbserver --once :2347 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
Process /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2 created; pid = 18637
Cannot exec /home/pedro/brno/pedro/gdb/mygit/build/gdb/testsuite/outputs/gdb.server/solib-list/ld-linux-x86-64.so.2: No such file or directory.
...
The test copied the interpreter to the outputs directory, however
ld-linux-x86-64.so.2 is a relative symlink that when copied points
nowhere:
$ ls -l testsuite/outputs/gdb.server/solib-list/
total 52
-rwxrwxr-x. 1 pedro pedro 13450 Apr 7 10:52 gdb.log
-rw-rw-r--. 1 pedro pedro 1512 Apr 7 10:52 gdb.sum
lrwxrwxrwx. 1 pedro pedro 10 Apr 7 11:39 ld-linux-x86-64.so.2 -> ld-2.22.so
-rwxrwxr-x. 1 pedro pedro 9464 Apr 7 11:39 solib-list
-rw-rw-r--. 1 pedro pedro 3472 Apr 7 11:39 solib-list-lib.c.o
-rw-rw-r--. 1 pedro pedro 2760 Apr 7 11:39 solib-list.o
-rwxrwxr-x. 1 pedro pedro 9232 Apr 7 11:39 solib-list.so
The copying comes from gdbserver_spawn ->
gdbserver_download_current_prog -> gdb_remote_download.
There's actually no need to download the interpreter to the target -
it's part of the target system/environment. So fix this by making the
test just not use gdb_load (and gdb_file_cmd as consequence) at all,
and instead pass the interpreter filename to gdbserver as an argument.
gdb/testsuite/ChangeLog:
2016-04-08 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: Don't use gdb_load. Instead pass the
interpreter filename as argument to gdbserver_spawn.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Return empty if $last_loaded_file does not exist.
This patch removes gdb_download in favor of gdb_remote_download, since
they are very close in functionality. Also, in preparation for the
following patch about shared library handling during tests, it improves
gdb_remote_download so that it uses standard_output_file for any
destination board that is local, not only host.
If the destination board is remote, gdb_remote_download will use the
standard remote_download from DejaGnu, resulting in the file being
transferred on the remote system.
If the destination is local, gdb_remote_download will copy the file to
the standard test directory (found using standard_output_file). Tcl's
file copy seems to handle gracefully cases where the source file is the
same as the destination, so I don't think it's necessary to check for
that case ourselves, as a previous version of the patch did.
I'd prefer to keep the name gdb_download instead of gdb_remote_download,
since I don't like the fact that gdb_remote_download implies that the
destination is remote, when it's not always the case. However,
gdb_remote_download is used at many more places than gdb_download, so
it's easier to reuse that. Also, since it's a wrapper around DejaGnu's
remote_download, it might be better to keep that name. I don't know.
I ran the testsuite native, with native-gdbserver and with a
remote gdbserver, and didn't see any related failure.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp: Use gdb_remote_download instead of
gdb_download. Use it even if the target is not remote.
* gdb.base/jit.exp (compile_jit_test): Likewise.
* lib/gdb.exp (gdb_remote_download): Copy files to the standard
output directory if the destination board is local, otherwise use
the standard remote_download from DejaGnu.
(gdb_download): Remove.
(gdb_load_shlibs): Use gdb_remote_download instead of
gdb_download.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Use gdb_remote_download instead of gdb_download. Use it even if
the target is not remote.
* lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download
instead of gdb_download.
We didn't test --wrapper option in extended-remote before, this patch
is to add a test case for it. In order to pass option --wrapper to
gdbserver in extended-remote, I add arg in gdbserver_start_extended,
and its default value is "", so that other places use
gdbserver_start_extended don't have to be updated.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdbserver_start_extended): Add
argument options.
* gdb.server/ext-wrapper.exp: New file.
Commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver) broke a couple tests that set gdbserver_reconnect_p and
restart gdb before reconnecting, because a gdb_exit (e.g., through
clean_restart) exits gdbserver unconditionally.
Fixes, with --target_board=native-gdbserver:
-FAIL: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint created
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: tracepoint on marker is installed
+PASS: gdb.trace/mi-tracepoint-changed.exp: reconnect: break-info 1
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
-FAIL: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv1 created
+PASS: gdb.trace/mi-tsv-changed.exp: upload: tsv2 created
gdb/testsuite/
2015-04-16 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (gdb_exit): If gdbserver_reconnect_p
is set, don't exit gdbserver.
I see the error when I run gdb-sigterm.exp with native-gdbserver
on x86_64-linux.
infrun: prepare_to_wait^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
gdb.base/gdb-sigterm.exp: expect eof #0: got eof
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 12 times
ERROR OCCURED: : spawn id exp8 not open
while executing
"expect {
-i exp8 -timeout 10
-re "$gdb_prompt $" {
exp_continue
}
-i "$server_spawn_id" eof {
wait -i $expect_out(spawn_id)
unse..."
("uplevel" body line 1)
invoked from within
In gdb-sigterm.exp, SIGTERM is sent to GDB and it exits. However,
Dejagnu or tcl doesn't know this.
This patch is to catch the exception, but error messages are still
shown in the console and gdb.log. In order to avoid this, we also
replace gdb_expect with expect.
gdb/testsuite:
2015-04-13 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (gdb_exit): Catch exception
and use expect instead of gdb_expect.
Some important tests, like gdb.base/interrupt.exp end up skipped
against gdbserver, because they depend on inferior I/O, which
gdbserver doesn't do.
This patch adds a mechanism that makes it possible to make them work.
It adds a new "inferior_spawn_id" global that is the spawn ID used for
I/O interaction with the inferior. By default, for native targets, or
remote targets that can do I/O through GDB (semi-hosting) this will be
the same as the gdb/host spawn ID. Otherwise, the board may set this
to some other spawn ID. When debugging with GDBserver, this will be
set to GDBserver's spawn ID.
Then tests can use send_inferior instead of send_gdb to send input to
the inferior, and use expect's "-i" switch to select which spawn ID to
use for matching input/output. That is, something like this will now
work:
send_inferior "echo me\n"
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "echo me\r\necho\r\n" {
...
}
}
Or even:
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "hello world" {
...
}
-i "$gdb_spawn_id" -re "error.*$gdb_prompt $" {
...
}
}
Of course, by default, gdb_test_multiple still matches with
$gdb_spawn_id.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (inferior_spawn_id): New global.
(gdb_test_multiple): Handle "-i". Reset the spawn id to GDB's
spawn id after processing the user code.
(default_gdb_start): Set inferior_spawn_id.
(send_inferior): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Set
inferior_spawn_id.
(close_gdbserver, gdb_exit): Unset inferior_spawn_id.
I adjusted a test to do 'expect -i $server_spawn_id -re ...', and saw
really strange behavior. Whether that expect would work, depended on
whether GDB would also send output and the same expect matched it too
(on $gdb_spawn_id). I was perplexed until I noticed that
gdbserver_spawn spawns gdbserver and then uses expect_background to
reap gdbserver. That expect_background conflicts/races with any
"expect -i $server_spawn_id" done anywhere else in parallel...
In order to make it possible for tests to read inferior I/O out of
$server_spawn_id, we to get rid of that expect_background. This patch
makes us instead reap gdbserver's spawn id when GDB exits. If GDB is
still around, this gives a chance for gdbserver to exit cleanly. The
current code in gdb_finish uses "kill", but that doesn't work with
extended-remote (gdbserver doesn't exit). We now use "monitor exit"
instead which works in both remote and extended-remote modes.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_finish): Delete persistent gdbserver handling.
* lib/gdbserver-support.exp (gdbserver_start): Make
$server_spawn_id global.
(gdbserver_start): Don't wait for gdbserver's spawn id with
expect_background.
(close_gdbserver): New procedure.
(gdb_exit): Rename the default version and reimplement.
As it happens we have a board that fails a gdb.base/gcore-relro.exp
test case reproducibly and moreover the case appears to trigger a
kernel bug making the it less than usable. Specifically the board
remains responsive to some extent, however processes do not appear
to be able to successfully complete termination anymore and perhaps
more importantly further gdbserver processes can be started, but they
never reach the stage of listening on the RSP socket.
This change handles timeouts in gdbserver start properly, by throwing
a TCL error exception when gdbserver does not report listening on the
RSP socket in time. This is then caught at the outer level and
reported, and 2 rather than 1 is returned so that the caller may tell
the failure to start gdbserver and other issues apart and act
accordingly (or do nothing).
I thought letting the exception unwind further on might be a good idea
for any test harnesses out there to break outright where a gdbserver
start error is silently ignored right now, however I figured out the
calls to gdbserver-support.exp are buried down too deep in the GDB test
suite for such a change to be made easily. I think returning a distinct
return value is good enough (the API says "non-zero", so 2 is as good as
1) and we can always make the error harder in a later step if required.
With config/gdbserver.exp being used this change remains transparent
to the target board, the return value is passed up by gdb_reload and
the error exception unwinds through gdbserver_gdb_load and is caught
and handled by mi_gdb_target_load. A call to perror is still made,
reporting the timeout, and in the case of mi_gdb_target_load the
procedure returns a value denoting unsuccessful completion. An
unsuccessful completion of gdb_reload is already handled elsewhere.
An alternative gdbserver board configuration can interpret the return
value in its gdb_reload implementation and catch the error in
gdbserver_gdb_load in an attempt to recover a target board that has
gone astray, for example by rebooting the board somehow. This has
proved effective with our failing board, that now completes the
remaining test cases with no further hiccups.
* lib/gdbserver-support.exp (gdbserver_start): Throw an error
exception on timeout.
(gdbserver_run): Catch any `gdbserver_spawn' error exceptions.
(gdbserver_start_extended): Catch any `gdbserver_start' error
exceptions.
(gdbserver_start_multi, mi_gdbserver_start_multi): Likewise.
* lib/mi-support.exp (mi_gdb_target_load): Catch any
`gdbserver_gdb_load' error exceptions.
Gdbserver support code uses the global timeout value to determine when
to stop waiting for a gdbserver process being started to respond before
continuing anyway. This timeout is usually as low as 10s and may not
be enough in this context, for example on the first run where the
filesystem cache is cold, even if it is elsewhere.
E.g. I observe this reliably with gdbserver started the first time in
QEMU running in the system emulation mode:
(gdb) file .../gdb.base/advance
Reading symbols from .../gdb.base/advance...done.
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x87f8: file .../gdb.base/advance.c,
line 41.
(gdb) set remotetimeout 15
(gdb) kill
The program is not being run.
(gdb)
[...]
.../bin/gdbserver --once :6014 advance
target remote localhost:6014
Remote debugging using localhost:6014
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) continue
The program is not being run.
(gdb) Process advance created; pid = 999
Listening on port 6014
FAIL: gdb.base/advance.exp: Can't run to main
-- notice how the test harness proceeded with the `target remote ...'
command even though gdbserver hasn't completed its startup yet. A
while later when it's finally ready it's too late already. I checked
the timing here and it takes gdbserver roughly 25 seconds to start in
this scenario. Subsequent gdbserver starts in the same test run take
less time and usually complete within 10 seconds although occasionally
`target remote ...' precedes the corresponding `Listening on port...'
message again.
Therefore I have fixed this problem by setting an explicit timeout to
120s on the expect call in question. If this turns out too arbitrary
sometime, then perhaps a separate `gdbserver_timeout' setting might be
due.
* lib/gdbserver-support.exp (gdbserver_start): Set timeout to
120 on waiting for the TCP socket to open.
* lib/gdbserver-support.exp (gdbserver_default_get_remote_address):
Add comment.
(gdbserver_default_get_comm_port): New function.
(gdbserver_start): Check if board file provided
"gdbserver,get_comm_port" and use it if so.
* boards/native-stdio-gdbserver.exp (sockethost): Set to "".
(gdb,socketport): Set to "stdio".
(gdbserver,get_comm_port): Set to ${board}_get_comm_port.
(stdio_gdbserver_template): Delete.
(${board}_get_remote_address): Update.
(${board}_build_remote_cmd): Delete.
(${board}_get_comm_port): New function.
(${board}_spawn): Update.
* boards/remote-stdio-gdbserver.exp (${board}_build_remote_cmd):
Delete.
(${board}_get_remote_address): Update.
(${board}_get_comm_port): New function.
Two modifications:
1. The addition of 2013 to the copyright year range for every file;
2. The use of a single year range, instead of potentially multiple
year ranges, as approved by the FSF.
* gdb.server/ext-attach.exp: Make sure gdb is disconnected.
* gdb.server/ext-run.exp: Make sure gdb is disconnected.
* gdb.server/file-transfer.exp: Make sure gdb is disconnected.
* gdb.server/server-mon.exp: Make sure gdb is disconnected.
* gdb.server/server-run.exp: Make sure gdb is disconnected.
* lib/gdbserver-support.exp (gdbserver_start_extended): Only
prepend "extended-" to $gdbserver_protocol if $gdbserver_protocol
doesn't start with "extended-" already.
