binutils-gdb/gdb/testsuite/gdb.server/multi-ui-errors.exp
Simon Marchi 8dc558a072 gdb/testsuite: avoid reading files through the remote protocol in gdb.server/*.exp
When I run some tests in gdb.server (fox example
gdb.server/ext-attach.exp) on Ubuntu 20.04 with separate debug info for
glibc installed, they often time out.  This is because GDB reads the
debug info through the remote protocol which is particularly slow:

    attach 316937
    Attaching to program: /home/smarchi/build/binutils-gdb-all-targets/gdb/testsuite/outputs/gdb.server/ext-attach/ext-attach, process 316937
    Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6...
    Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target...
    Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target...
    Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target...
    FAIL: gdb.server/ext-attach.exp: attach to remote program 1 (timeout)

This is avoided in gdbserver boards by adding "set sysroot" to GDBFLAGS
(see boards/local-board.exp), which makes GDB read files from the local
filesystem.  But gdb.server tests spawn GDBserver directly, so are ran
even when using the default unix board, where the "set sysroot" isn't
used.

Modify these tests to append "set sysroot" to the GDBFLAGS, a bit like
lib/local-board.exp does.

One special case is gdb.server/sysroot.exp, whose intent is to test
different "set sysroot" values.  For this one, increase the timeout when
testing the "target:" sysroot.

gdb/testsuite/ChangeLog:

	* gdb.server/abspath.exp: Append "set sysroot" to GDBFLAGS.
	* gdb.server/connect-without-multi-process.exp: Likewise.
	* gdb.server/exit-multiple-threads.exp: Likewise.
	* gdb.server/ext-attach.exp: Likewise.
	* gdb.server/ext-restart.exp: Likewise.
	* gdb.server/ext-run.exp: Likewise.
	* gdb.server/ext-wrapper.exp: Likewise.
	* gdb.server/multi-ui-errors.exp: Likewise.
	* gdb.server/no-thread-db.exp: Likewise.
	* gdb.server/reconnect-ctrl-c.exp: Likewise.
	* gdb.server/run-without-local-binary.exp: Likewise.
	* gdb.server/server-kill.exp: Likewise.
	* gdb.server/server-run.exp: Likewise.
	* gdb.server/solib-list.exp: Likewise.
	* gdb.server/stop-reply-no-thread.exp: Likewise.
	* gdb.server/wrapper.exp: Likewise.
	* gdb.server/sysroot.exp: Increase timeout when testing the
	target: sysroot.

Change-Id: I7451bcc737f90e2cd0b977e9f09da3710774b0bf
2021-01-04 11:43:59 -05:00

117 lines
3.5 KiB
Plaintext

# This testcase is part of GDB, the GNU debugger.
#
# Copyright 2019-2021 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Test what happens if we have multiple UIs in use, and an error
# occurs while running a GDB command. Specifically, do both UIs
# return to an interactive state, or does one (or both) of them get
# stuck in a non-interactive state.
load_lib gdbserver-support.exp
standard_testfile
if {[skip_gdbserver_tests]} {
return 0
}
save_vars { GDBFLAGS } {
# If GDB and GDBserver are both running locally, set the sysroot to avoid
# reading files via the remote protocol.
if { ![is_remote host] && ![is_remote target] } {
set GDBFLAGS "$GDBFLAGS -ex \"set sysroot\""
}
if {[prepare_for_testing "failed to prepare" ${testfile} ${srcfile}]} {
return -1
}
}
# Make sure we're disconnected, in case we're testing with an
# extended-remote board, therefore already connected.
gdb_test "disconnect" ".*"
# Start gdbserver.
set res [gdbserver_spawn "${binfile}"]
set gdbserver_protocol [lindex $res 0]
set gdbserver_gdbport [lindex $res 1]
set gdbserver_pid [exp_pid -i $server_spawn_id]
# Save the main UI's spawn ID.
set gdb_main_spawn_id $gdb_spawn_id
# Create the new PTY for the secondary console UI, issue the 'new-ui'
# command, and wait for a prompt on the second UI.
spawn -pty
set extra_spawn_id $spawn_id
set extra_tty_name $spawn_out(slave,name)
gdb_test_multiple "new-ui console $extra_tty_name" "new-ui" {
-re "New UI allocated\r\n$gdb_prompt $" {
pass $gdb_test_name
}
}
with_spawn_id $extra_spawn_id {
gdb_test_multiple "" "initial prompt on extra console" {
-re "$gdb_prompt $" {
pass $gdb_test_name
}
}
}
# Connect to the remote and continue its execution from the other UI.
with_spawn_id $extra_spawn_id {
gdb_test "target $gdbserver_protocol $gdbserver_gdbport" ".*" \
"connect to gdbserver"
send_gdb "continue\n"
}
# We're going to kill the gdbserver, but before we do, lets make sure
# that the inferior has started executing.
with_spawn_id $server_spawn_id {
gdb_test_multiple "" "ensure inferior is running" {
-re "@@XX@@ Inferior Starting @@XX@@" {
pass $gdb_test_name
}
timeout {
fail $gdb_test_name
}
}
}
# Interact with the main UI.
with_spawn_id $gdb_main_spawn_id {
gdb_test "echo hello\\n" "hello" "interact with GDB's main UI"
}
# Now kill the gdbserver.
remote_exec target "kill -9 $gdbserver_pid"
# We expect to land back at a GDB prompt in both UIs, however there is
# currently an issue that in the original UI GDB doesn't reprint its
# prompt. That said, getting a prompt isn't the point of this test.
# The point is that we should be able to interact with GDB from either
# interpreter now.
with_spawn_id $gdb_main_spawn_id {
gdb_test "echo" "" \
"main UI, prompt after gdbserver dies"
}
with_spawn_id $extra_spawn_id {
gdb_test "echo" "" \
"extra UI, prompt after gdbserver dies"
}