Fix a commit f90183d7e3 ("Get GDBserver pid on remote target") bug and
correctly handle the case where the PID of `gdbserver' could not have
been retrieved. If that happens, $server_pid is unset causing:
FAIL: gdb.server/server-kill.exp: p server_pid
ERROR: tcl error sourcing .../gdb/testsuite/gdb.server/server-kill.exp.
ERROR: can't read "server_pid": no such variable
while executing
"if {$server_pid == "" } {
return -1
}"
(file ".../gdb/testsuite/gdb.server/server-kill.exp" line 49)
invoked from within
"source .../gdb/testsuite/gdb.server/server-kill.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source .../gdb/testsuite/gdb.server/server-kill.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Verify that the variable exists then rather than trying to access it.
gdb/testsuite/
* gdb.server/server-kill.exp: Verify whether `server_pid' exists
rather then trying to access it in determining whether the PID
of `gdbserver' could have been retrieved.
Simon mentioned on IRC that, after the startup-with-shell feature has
been implemented on gdbserver, it is not possible to specify a
filename-only binary, like:
$ gdbserver :1234 a.out
/bin/bash: line 0: exec: a.out: not found
During startup program exited with code 127.
Exiting
This happens on systems where the current directory "." is not listed
in the PATH environment variable. Although including "." in the PATH
variable is a possible workaround, this can be considered a regression
because before startup-with-shell it was possible to use only the
filename (due to reason that gdbserver used "exec*" directly).
The idea of the patch is to verify if the program path provided by the
user (or by the remote protocol) contains a directory separator
character. If it doesn't, it means we're dealing with a filename-only
binary, so we call "gdb_abspath" to properly expand it and transform
it into a full path. Otherwise, we leave the program path untouched.
This mimicks the behaviour seen on GDB (look at "openp" and
"attach_inferior", for example).
I am also submitting a testcase which exercises the scenario described
above. This test requires gdbserver to be executed in a different CWD
than the original, so I also created a helper function, "with_cwd" (on
testsuite/lib/gdb.exp), which takes care of cd'ing into and out of the
specified dir.
Built and regtested on BuildBot, without regressions.
gdb/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* common/common-utils.c: Include "sys/stat.h".
(is_regular_file): Move here from "source.c"; change return
type to "bool".
* common/common-utils.h (is_regular_file): New prototype.
* common/pathstuff.c (contains_dir_separator): New function.
* common/pathstuff.h (contains_dir_separator): New prototype.
* source.c: Don't include "sys/stat.h".
(is_regular_file): Move to "common/common-utils.c".
gdb/gdbserver/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c: Include "filenames.h" and "pathstuff.h".
(program_name): Delete variable.
(program_path): New anonymous class.
(get_exec_wrapper): Use "program_path" instead of
"program_name".
(handle_v_run): Likewise.
(captured_main): Likewise.
(process_serial_event): Likewise.
gdb/testsuite/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.server/abspath.exp: New file.
* lib/gdb.exp (with_cwd): New procedure.
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>,
Maciej reported that commit:
commit 5cd63fda03
Date: Wed Oct 4 18:21:10 2017 +0100
Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
made GDB stop working with older stubs. Any attempt to continue
execution after the initial connection fails with:
[...]
Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
Listening on port 2346
target remote [...]:2346
Remote debugging using [...]:2346
Reading symbols from .../lib64/ld.so.1...done.
[Switching to Thread <main>]
(gdb) continue
Cannot execute this command without a live selected thread.
(gdb)
The problem is:
(gdb) c
Cannot execute this command without a live selected thread.
(gdb) info threads
Id Target Id Frame
1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2
The current thread <Thread ID 2> has terminated. See `help thread'.
^^^^^^^^^^^
(gdb)
Note, thread _2_. There's really only one thread in the inferior
(it's still at the entry point), but still GDB added a bogus second
thread.
The reason GDB started adding a second thread after 5cd63fda03 is
this hunk:
+ if (event->ptid == null_ptid)
+ {
+ const char *thr = strstr (p1 + 1, ";thread:");
+ if (thr != NULL)
+ event->ptid = read_ptid (thr + strlen (";thread:"),
+ NULL);
+ else
+ event->ptid = magic_null_ptid;
+ }
Note the else branch that falls back to magic_null_ptid. We reach
that when we process the initial stop reply sent back in response to
the the "?" (status) packet early in the connection setup:
Sending packet: $?#3f...Ack
Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000;
And note that that response does not include a ";thread:XXX" part.
This stop reply is processed after listing threads with qfThreadInfo /
qsThreadInfo :
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m3915
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
meaning, when we process that stop reply, we treat the event as coming
from a thread with ptid == magic_null_ptid, which is not yet in the
thread list, so we add it then:
(top-gdb) p ptid
$1 = {m_pid = 42000, m_lwp = -1, m_tid = 1}
(top-gdb) bt
#0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269
#1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0)
at src/gdb/remote.c:1838
#2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0)
at src/gdb/remote.c:1921
#3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00)
at src/gdb/remote.c:7217
#4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/remote.c:7380
#5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446
#6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138
#7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/target.c:2179
#8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/infrun.c:3589
#9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707
#10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212
things go downhill from this.
We don't see the problem with current master gdbserver, because that
version always sends the ";thread:" part in the initial stop reply:
Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3;
Years ago I had added a "--disable-packet=" command line option to
gdbserver which comes in handy for testing this, since the existing
"--disable-packet=Tthread" precisely makes gdbserver not send that
";thread:" part in stop replies. The testcase added by this commit
emulates old gdbserver making use of that.
I've compared a testrun at 5cd63fda035d^ (before regression) with
'current master+patch', against old gdbserver at f8b73d13b7ca^. I
hacked out --once, and "monitor exit" to be able to test. The results
are a bit too unstable to tell accurately, but it looked like there
were no regressions. Maciej confirmed this worked for him as well.
No regressions on master (against master gdbserver).
gdb/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* remote.c (remote_parse_stop_reply): Default to the last-set
general thread instead of to 'magic_null_ptid'.
gdb/testsuite/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* gdb.server/stop-reply-no-thread.c: New file.
* gdb.server/stop-reply-no-thread.exp: New file.
When we set bfd/development.sh:$development to false, GDBserver failed to
build,
selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status
selftest.o shouldn't be compiled and linked when $development is false.
With this patch, in release mode, GDBserver doesn't nothing with option
--selftest,
$ ./gdbserver --selftest=foo
Selftests are not available in a non-development build.
$ ./gdbserver --selftest
Selftests are not available in a non-development build.
gdb/gdbserver:
2018-01-08 Yao Qi <yao.qi@linaro.org>
Simon Marchi <simon.marchi@ericsson.com>
* Makefile.in (OBS): Remove selftest.o.
* configure.ac: Set srv_selftest_objs if $development is true.
(GDBSERVER_DEPFILES): Append $srv_selftest_objs.
* configure: Re-generated.
* server.c (captured_main): Wrap variable selftest_filter with
GDB_SELF_TEST.
gdb/testsuite:
2018-01-08 Simon Marchi <simon.marchi@ericsson.com>
* gdb.server/unittest.exp: Match the output in non-development
mode.
This fixes the issue reported by Dmitry Antipov <dantipov@nvidia.com>
here:
https://sourceware.org/ml/gdb/2017-10/msg00048.html
The problem is that GDBserver stops listening to Ctrl-C/interrupt
requests if you disconnect and reconnect back.
Dmitry wrote:
~~~
Currently gdbserver installs SIGIO handler just once, in
initialize_async_io() called from captured_main(), and this handler is
removed when remote_desc is closed in remote_close(). Next, when a
new instance of remote_desc is fetched from accept() and has '\003'
arrived, input_interrupt() is never called because it is not
registered as SIGIO handler.
~~~
The fix here is not remove the SIGIO handler in the first place, thus
going back to the original before-first-connection state.
(I haven't gone back to try it, but I think this was a regression
caused by commit 8b20733984 ("[GDBserver] Block and unblock SIGIO"),
which was what made remote_close remove the signal handler.)
New test included.
gdb/gdbserver/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* remote-utils.c (remote_close): Block SIGIO signals instead of
uninstalling the SIGIO handler.
gdb/testsuite/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* gdb.server/reconnect-ctrl-c.c: New file.
* gdb.server/reconnect-ctrl-c.exp: New file.
This commit fixes this same problem in several places:
(gdb) PASS: gdb.multi/multi-attach.exp: backtrace 2
kill
Kill the program being debugged? (y or n) y
(gdb) FAIL: gdb.multi/multi-attach.exp: kill inferior 2 (got interactive prompt)
This is just another case of the gdb_test_multiple's internal "got
interactive prompt" pattern matching because the testcase misses
matching enough.
gdb/testsuite/ChangeLog:
2017-11-09 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-attach.exp ("kill" test): Match the whole query
output.
* gdb.server/ext-attach.exp ("kill" test): Likewise.
* gdb.server/ext-restart.exp ("kill" test): Likewise.
* gdb.server/ext-run.exp ("kill" test): Likewise.
* gdb.server/ext-wrapper.exp ("kill" test): Likewise.
There is an assertion that is triggering when we start GDB and
instruct it to debug a remote inferior, but don't provide a local
binary, like:
./gdb -nx -q --data-directory=data-directory -ex "tar ext :1234" \
-ex "set remote exec-file /bin/ls" -ex r
In this case, when calling exec_file_locate_attach to locate the
inferior, GDB is incorrectly resetting the breakpoints without a
thread/inferior even running, which causes an assertion to be
triggered:
binutils-gdb/gdb/thread.c:1609: internal-error: scoped_restore_current_thread::scoped_restore_current_thread(): Assertion `tp != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This happens because add_current_inferior_and_thread (on remote.c) is
breaking an invariant: making inferior_ptid point to a non-existing
thread and then calling common code, which in this case is
breakpoint_re_set. The fix is to make sure that inferior_ptid points
to null_ptid if there is no thread present.
A testcase is provided. Regtested on buildbot.
gdb/ChangeLog:
2017-08-23 Pedro Alves <palves@redhat.com>
PR remote/21852
* remote.c (add_current_inferior_and_thread): Set inferior_ptid
to null_ptid and switch to thread without reading the registers
after adding the inferior.
gdb/testsuite/ChangeLog:
2017-08-23 Sergio Durigan Junior <sergiodj@redhat.com>
PR remote/21852
* gdb.server/normal.c: New file, copied from gdb.base.
* gdb.server/run-without-local-binary.exp: New file.
This patch uses GDB self test in GDBserver. The self tests are run if
GDBserver is started with option --selftest.
gdb:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* NEWS: Mention GDBserver's new option "--selftest".
* Makefile.in (SFILES): Remove selftest.c, add common/selftest.c.
* selftest.c: Move it to common/selftest.c.
* selftest.h: Move it to common/selftest.h.
* selftest-arch.c (reset): New function.
(tests_with_arch): Call reset.
gdb/gdbserver:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* Makefile.in (OBS): Add selftest.o.
* configure.ac: AC_DEFINE GDB_SELF_TEST if $development.
* configure, config.in: Re-generated.
* server.c: Include common/sefltest.h.
(captured_main): Handle option --selftest.
gdb/testsuite:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.server/unittest.exp: New.
gdb/doc:
2017-08-18 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (Server): Document "--selftest".
This is the most important (and the biggest, sorry) patch of the
series. It moves fork_inferior from gdb/fork-child.c to
nat/fork-inferior.c and makes all the necessary adjustments to both
GDB and gdbserver to make sure everything works OK.
There is no "most important change" with this patch; all changes are
made in a progressive way, making sure that gdbserver had the
necessary features while not breaking GDB at the same time.
I decided to go ahead and implement a partial support for starting the
inferior with a shell on gdbserver, although the full feature comes in
the next patch. The user won't have the option to disable the
startup-with-shell, and also won't be able to change which shell
gdbserver will use (other than setting the $SHELL environment
variable, that is).
Everything is working as expected, and no regressions were present
during the tests.
gdb/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add "common/common-inferior.h"
and "nat/fork-inferior.h".
* common/common-inferior.h: New file, with contents from
"gdb/inferior.h".
* commom/common-utils.c: Include "common-utils.h".
(stringify_argv): New function.
* common/common-utils.h (stringify_argv): New prototype.
* configure.nat: Add "fork-inferior.o" as a dependency for
"*linux*", "fbsd*" and "nbsd*" hosts.
* corefile.c (get_exec_file): Update comment.
* darwin-nat.c (darwin_ptrace_him): Call "gdb_startup_inferior"
instead of "startup_inferior".
(darwin_create_inferior): Call "add_thread_silent" after
"fork_inferior".
* fork-child.c: Cleanup unnecessary includes.
(SHELL_FILE): Move to "common/common-fork-child.c".
(environ): Likewise.
(exec_wrapper): Initialize.
(get_exec_wrapper): New function.
(breakup_args): Move to "common/common-fork-child.c"; rename to
"breakup_args_for_exec".
(escape_bang_in_quoted_argument): Move to
"common/common-fork-child.c".
(saved_ui): New variable.
(prefork_hook): New function.
(postfork_hook): Likewise.
(postfork_child_hook): Likewise.
(gdb_startup_inferior): Likewise.
(fork_inferior): Move to "common/common-fork-child.c". Update
function to support gdbserver.
(startup_inferior): Likewise.
* gdbcore.h (get_exec_file): Remove declaration.
* gnu-nat.c (gnu_create_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* inf-ptrace.c: Include "nat/fork-inferior.h" and "utils.h".
(inf_ptrace_create_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* inferior.h: Include "common-inferior.h".
(trace_start_error): Move to "common/common-utils.h".
(trace_start_error_with_name): Likewise.
(fork_inferior): Move prototype to "nat/fork-inferior.h".
(startup_inferior): Likewise.
(gdb_startup_inferior): New prototype.
* nat/fork-inferior.c: New file, with contents from "fork-child.c".
* nat/fork-inferior.h: New file.
* procfs.c (procfs_init_inferior): Call "gdb_startup_inferior"
instead of "startup_inferior". Call "add_thread_silent" after
"fork_inferior".
* target.h (target_terminal_init): Move prototype to
"target/target.h".
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* target/target.h (target_terminal_init): New prototype, moved
from "target.h".
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* utils.c (gdb_flush_out_err): New function.
gdb/gdbserver/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* Makefile.in (SFILES): Add "nat/fork-inferior.o".
* configure: Regenerate.
* configure.srv (srv_linux_obj): Add "fork-child.o" and
"fork-inferior.o".
(i[34567]86-*-lynxos*): Likewise.
(spu*-*-*): Likewise.
* fork-child.c: New file.
* linux-low.c: Include "common-inferior.h", "nat/fork-inferior.h"
and "environ.h".
(linux_ptrace_fun): New function.
(linux_create_inferior): Adjust function prototype to reflect
change on "target.h". Adjust function code to use
"fork_inferior".
(linux_request_interrupt): Delete "signal_pid".
* lynx-low.c: Include "common-inferior.h" and "nat/fork-inferior.h".
(lynx_ptrace_fun): New function.
(lynx_create_inferior): Adjust function prototype to reflect
change on "target.h". Adjust function code to use
"fork_inferior".
* nto-low.c (nto_create_inferior): Adjust function prototype and
code to reflect change on "target.h". Update comments.
* server.c: Include "common-inferior.h", "nat/fork-inferior.h",
"common-terminal.h" and "environ.h".
(terminal_fd): Moved to fork-child.c.
(old_foreground_pgrp): Likewise.
(restore_old_foreground_pgrp): Likewise.
(last_status): Make it global.
(last_ptid): Likewise.
(our_environ): New variable.
(startup_with_shell): Likewise.
(program_name): Likewise.
(program_argv): Rename to...
(program_args): ...this.
(wrapper_argv): New variable.
(start_inferior): Delete function.
(get_exec_wrapper): New function.
(get_exec_file): Likewise.
(get_environ): Likewise.
(prefork_hook): Likewise.
(post_fork_inferior): Likewise.
(postfork_hook): Likewise.
(postfork_child_hook): Likewise.
(handle_v_run): Update code to deal with arguments coming from the
remote host. Update calls from "start_inferior" to
"create_inferior".
(captured_main): Likewise. Initialize environment variable. Call
"have_job_control".
* server.h (post_fork_inferior): New prototype.
(get_environ): Likewise.
(last_status): Declare.
(last_ptid): Likewise.
(signal_pid): Likewise.
* spu-low.c: Include "common-inferior.h" and "nat/fork-inferior.h".
(spu_ptrace_fun): New function.
(spu_create_inferior): Adjust function prototype to reflect change
on "target.h". Adjust function code to use "fork_inferior".
* target.c (target_terminal_init): New function.
(target_terminal_inferior): Likewise.
(target_terminal_ours): Likewise.
* target.h: Include <vector>.
(struct target_ops) <create_inferior>: Update prototype.
(create_inferior): Update macro.
* utils.c (gdb_flush_out_err): New function.
* win32-low.c (win32_create_inferior): Adjust function prototype
and code to reflect change on "target.h".
gdb/testsuite/ChangeLog:
2017-06-07 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.server/non-existing-program.exp: Update regex in order to
reflect the fact that gdbserver is now using fork_inferior (with a
shell) to startup the inferior.
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.
Hi,
I happen to see gdbserver is spawned like this in gdb.log,
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
as we can see, there are two instances of connect-stopped-target or
connect-stopped-target in the command line spawning gdbserver, but
none of these gets parameters from command line. In these two
tests, gdbserver is spawned via "gdbserver_spawn ${binfile}". However,
the argument of gdbserver_spawn is the argument passed the child
inferior, not the program itself.
# Start a gdbserver process running SERVER_EXEC, and connect GDB
# to it. CHILD_ARGS are passed to the inferior.
#
# Returns the target protocol and socket to connect to.
proc gdbserver_spawn { child_args } {
set target_exec [gdbserver_download_current_prog]
GDBserver gets the program via last_loaded_file, which is set by
gdb_file_cmd. In each test, we don't need to pass ${binfile}.
gdb/testsuite:
2016-08-23 Yao Qi <yao.qi@linaro.org>
* gdb.server/connect-stopped-target.exp (do_test): Pass "" to
gdbserver_spawn.
* gdb.server/connect-without-multi-process.exp (do_test):
Likewise.
If I run single test solib-list.exp, it is OK. If I run two, as below,
there are fails,
$ make check RUNTESTFLAGS="server-run.exp solib-list.exp"
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
in gdb.log,
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/server-run/server-run /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
server-run is spawned, which is wrong. If I only run solib-list.exp, ld-linux
is spawned, which is right.
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
in test, we spawn gdbserver this way,
# Note we pass ${interp_system}, the program gdbserver spawns, as
# argument here, instead of using gdb_load, because we don't want
# to download the interpreter to the target (it's already there)
# or to the test output directory.
set res [gdbserver_spawn "${interp_system} ${remote_binfile}"]
in gdbserver_spawn -> gdbserver_download_current_prog, if
last_loaded_file is set (when you run multiple tests), it is
returned.
This patch is to unset last_loaded_file in solib-list.exp.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* gdb.server/solib-list.exp: Unset last_loaded_file.
This test exercises the scenarios where we attempt to connect GDB to GDBserver
in standard remote mode, query the symbol file path, attempt to open said
symbol file on GDB's end and fail, causing the connection to drop abruptly.
Regression-tested on x86-64/Ubuntu.
With an unpatched GDB we should see this:
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=delete: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=delete: connection to GDBserver succeeded (the program is no longer running)
A patched GDB should have full passes.
gdb/testsuite/ChangeLog:
2016-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.server/connect-with-no-symbol-file.c: New file.
* gdb.server/connect-with-no-symbol-file.exp: New file.
There are a few small changes needed to make it work with a real remote
target.
- Remove the [is_remote target] check.
- Remove soname setting when building the lib, it's done by default now
anyway.
- In the compilation of the executable, pass the shared lib using the
shlib option, so that RPATH is set.
- Download the program to the target using gdb_remote_download, and
record the remote path. Remove loading of the program using
gdb_load_shlibs, which was not really appropriate anyway.
- Run the remote path through readlink (see comment in the code).
- Start gdbserver with the remote path.
Also, don't set executable and objfile variables, as they are unused.
Tested with native, native-gdbserver, native-extended-gdbserver, and a
remote gdbserver.
gdb/testsuite/ChangeLog:
* gdb.server/solib-list.exp: Remove is_remote check.
Pass shlib= to gdb_compile. Don't link shared library with
-soname. Call gdb_remote_download instead of gdb_load_shlibs.
Run binary filename through "readlink -f" on the target.
Commit 7817ea4614 (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.
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
What do you think?
gdb/testsuite/ChangeLog:
* Makefile.in (ALL_SUBDIRS): Remove.
(clean mostlyclean): Do not recurse in ALL_SUBDIRS.
(distclean maintainer-clean realclean): Likewise.
* configure.ac (AC_OUTPUT): Remove gdb.*/Makefile.
* configure: Regenerate.
* gdb.ada/Makefile.in: Delete.
* gdb.arch/Makefile.in: Likewise.
* gdb.asm/Makefile.in: Likewise.
* gdb.base/Makefile.in: Likewise.
* gdb.btrace/Makefile.in: Likewise.
* gdb.cell/Makefile.in: Likewise.
* gdb.compile/Makefile.in: Likewise.
* gdb.cp/Makefile.in: Likewise.
* gdb.disasm/Makefile.in: Likewise.
* gdb.dlang/Makefile.in: Likewise.
* gdb.dwarf2/Makefile.in: Likewise.
* gdb.fortran/Makefile.in: Likewise.
* gdb.gdb/Makefile.in: Likewise.
* gdb.go/Makefile.in: Likewise.
* gdb.guile/Makefile.in: Likewise.
* gdb.java/Makefile.in: Likewise.
* gdb.linespec/Makefile.in: Likewise.
* gdb.mi/Makefile.in: Likewise.
* gdb.modula2/Makefile.in: Likewise.
* gdb.multi/Makefile.in: Likewise.
* gdb.objc/Makefile.in: Likewise.
* gdb.opencl/Makefile.in: Likewise.
* gdb.opt/Makefile.in: Likewise.
* gdb.pascal/Makefile.in: Likewise.
* gdb.perf/Makefile.in: Likewise.
* gdb.python/Makefile.in: Likewise.
* gdb.reverse/Makefile.in: Likewise.
* gdb.server/Makefile.in: Likewise.
* gdb.stabs/Makefile.in: Likewise.
* gdb.threads/Makefile.in: Likewise.
* gdb.trace/Makefile.in: Likewise.
* gdb.xml/Makefile.in: Likewise.
* lib/gdb.exp (make_gdb_parallel_path): Add check for
GDB_PARALLEL.
(standard_output_file): Remove check for GDB_PARALLEL, always
return path in outputs/$subdir/$testname.
Ref: https://sourceware.org/ml/gdb-patches/2015-08/msg00675.html
If multiprocess extensions are off (because specific gdbserver port
doesn't support them), then when gdbserver doesn't have a thread
selected yet, and GDB sends Hg packet to select one, gdbserver
crashes. That's because extracting the desired thread id out of the
packet that GDB sent depends on the current thread to fill in the
missing process id ... Fix this by getting the process id from the
first (and only) process in the processes list instead.
The GNU/Linux port doesn't trip on this because it always runs with
multiprocess extensions enabled. To make it easier to catch such
regressions going forward, this commit also adds a new smoke test that
spawns gdbserver, connects to it and runs to main with the
multiprocess extensions force-disabled.
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* inferiors.c (get_first_process): New function.
* inferiors.h (get_first_process): New declaration.
* remote-utils.c (read_ptid): Default to the first process in the
list, instead of to the current thread's process.
gdb/testsuite/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* gdb.server/connect-without-multi-process.c: New file.
* gdb.server/connect-without-multi-process.exp: New file.
Commit 221e1a37 (remote non-stop: Process initially stopped threads
before other commands) caused a test regression when testing with the
native-extended-gdbserver board:
FAIL: gdb.server/solib-list.exp: non-stop 1: non-stop interior stop (timeout)
This "interior stop" now happens before "target remote" prints the
prompt, so we should no longer explicitly expect it.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: No longer expect an interior stop in
non-stop mode.
The main motivation for this is making non-stop / all-stop behave
similarly on initial connection, in order to move in the direction of
reimplementing all-stop mode with the remote target always running in
non-stop mode.
When we connect to a remote target in non-stop mode, we may find
threads either running or already stopped. The act of connecting
itself does not force threads to stop. To handle that, the remote
non-stop connection is currently roughly like this:
#1 - Fetch list of remote threads (qXfer:threads:read, qfThreadInfo,
etc). All threads are assumed to be running until the target
reports an asynchronous stop reply for them.
#2 - Fetch the initial set of threads that were already stopped, with
the '?' packet. (In non-stop, this is coupled with the vStopped
mechanism to be able to retrieve the status of more than one
thread.)
The stop replies fetched in #2 are placed in the pending stop reply
queue, and left for the regular event loop to process. That is,
"target remote" finishes and returns _before_ those stops are
processed.
That means that it's possible to have GDB process further commands
before the initial set of stopped threads is reported to the user.
E.g., before the patch, note how the prompt is printed before the
frame:
Remote debugging using :9999
(gdb)
[Thread 15296] #1 stopped.
0x0000003615a011f0 in ?? ()
Even though thread #1 was not running, for a moment, the user can see
it as such:
$ gdb a.out -ex "set non-stop 1" -ex "tar rem :9999" -ex "info threads" -ex "info registers"
Remote debugging using :9999
Id Target Id Frame
* 1 Thread 4772 (running)
Target is executing. <<<<<<< info registers
(gdb)
[Thread 4772] #1 stopped.
0x0000003615a011f0 in ?? ()
To fix that, this commit makes gdb process all threads found already
stopped at connection time, before giving the prompt to the user.
The fix takes a cue from fork-child.c:startup_inferior [1], and
processes the events locally in remote.c, avoiding the whole
wait_for_inferior/handle_inferior_event path. I decided to try this
approach after noticing that:
- several cases in handle_inferior_event miss checking stop_soon.
- we don't want to fetch the thread list in normal_stop.
and trying to fix them was resulting in sprinkling stop_soon checks in
many places, and uglifying normal_stop even more.
While with this patch, I'm avoiding changing GDB's output other than
when the prompt is printed, I think this approach is more flexible if
we do want to change it. And also, it's likely easier to get rid of
the MI *running event that is still sent for threads that are
initially found stopped, if we want to.
This happens to fix the testsuite too. All non-stop tests are racy
against "target remote" / gdbserver testing currently. That is,
sometimes the tests run, but other times they're just skipped without
any indication of PASS/FAIL. When that happens, the logs show:
target remote localhost:2346
Remote debugging using localhost:2346
(gdb)
[Thread 25418] #1 stopped.
0x0000003615a011f0 in ?? ()
^CQuit
(gdb) Remote debugging from host 127.0.0.1
Killing process(es): 25418
monitor exit
(gdb) Remote connection closed
(gdb) testcase /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/multi-create-ns-info-thr.exp completed in 61 seconds
The trouble here is that there's output after the prompt, and the
regex in question doesn't expect that:
-re "Remote debugging using .*$serialport_re.*$gdb_prompt $" {
verbose "Set target to $targetname"
return 0
}
[1] - before startup_inferior was added, we'd go through
wait_for_inferior/handle_inferior_event while going through the shell,
and that turned out problematic.
Tested on x86_64 Fedora 20, gdbserver.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* infrun.c (print_target_wait_results): Make extern.
* infrun.h (print_target_wait_results): Declare.
* remote.c (set_stop_requested_callback): Delete.
(process_initial_stop_replies): New function.
(remote_start_remote): Use it.
(stop_reply_queue_length): New function.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/connect-stopped-target.c: New file.
* gdb.server/connect-stopped-target.exp: New file.
The buildbots show that attach-many-short-lived-thread.exp is racy.
But after staring at debug logs and playing with SystemTap scripts for
a (long) while, I figured out that neither GDB, nor the kernel nor the
test's program itself are at fault.
The problem is simply that the testsuite machinery is currently
subject to PID-reuse races. The attach-many-short-lived-threads.c
test program just happens to be much more susceptible to trigger this
race because threads and processes share the same number space on
Linux, and the test spawns many many short lived threads in
succession, thus enlarging the race window a lot.
Part of the problem is that several tests spawn processes with "exec&"
(in order to test the "attach" command) , and then at the end of the
test, to make sure things are cleaned up, issue a 'remote_spawn "kill
-p $testpid"'. Since with tcl's "exec&", tcl itself is responsible
for reaping the process's exit status, when we go kill the process,
testpid may have already exited _and_ its status may have (and often
has) been reaped already. Thus it can happen that another process
meanwhile reuses $testpid, and that "kill" command kills the wrong
process... Frequently, that happens to be
attach-many-short-lived-thread, but this explains other test's races
as well.
In the attach-many-short-lived-threads test, it sometimes manifests
like this:
(gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads...done.
(gdb) Loaded /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads into /home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb
attach 5940
Attaching to program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads, process 5940
warning: process 5940 is a zombie - the process has already terminated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ptrace: Operation not permitted.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach
info threads
No threads.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads
set breakpoint always-inserted on
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on
Other times the process dies while the test is ongoing (the process is
ptrace-stopped):
(gdb) print again = 1
Cannot access memory at address 0x6020cc
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior
(Recall that on Linux, SIGKILL is not interceptable)
And other times it dies just while we're detaching:
$4 = 319
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left
detach
Can't detach Thread 0x7fb13b7de700 (LWP 1842): No such process
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach
GDB mishandles the latter (it should ignore ESRCH while detaching just
like when continuing), but that's another story.
The fix here is to change spawn_wait_for_attach to use Expect's
'spawn' command instead of Tcl's 'exec&' to spawn programs, because
with spawn we control when to wait for/reap the process. That allows
killing the process by PID without being subject to pid-reuse races,
because even if the process is already dead, the kernel won't reuse
the process's PID until the zombie is reaped.
The other part of the problem lies in DejaGnu itself, unfortunately.
I have occasionally seen tests (attach-many-short-lived-threads
included, but not only that one) die with a random inexplicable
SIGTERM too, and that too is caused by the same reason, except that in
that case, the rogue SIGTERM is sent from this bit in DejaGnu's remote.exp:
exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $pid) &"
...
catch "wait -i $shell_id"
Even if the program exits promptly, that whole cascade of kills
carries on in the background, thus potentially killing the poor
process that manages to reuse $pid...
I sent a fix for that to the DejaGnu list:
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html
With both patches in place, I haven't seen
attach-many-short-lived-threads.exp fail again.
Tested on x86_64 Fedora 20, native, gdbserver and extended-gdbserver.
gdb/testsuite/ChangeLog:
2015-07-31 Pedro Alves <palves@redhat.com>
* gdb.base/attach-pie-misread.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* gdb.base/attach-pie-noexec.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/attach-twice.exp: Likewise.
* gdb.base/attach.exp: Likewise.
(do_command_attach_tests): Use gdb_spawn_with_cmdline_opts and
gdb_test_multiple.
* gdb.base/solib-overlap.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/valgrind-infcall.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.threads/attach-into-signal.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.threads/attach-many-short-lived-threads.exp: Adjust to
spawn_wait_for_attach returning a spawn id instead of a pid. Use
spawn_id_get_pid and kill_wait_spawned_process.
* gdb.threads/attach-stopped.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/break-interp.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* lib/gdb.exp (can_spawn_for_attach): Adjust comment.
(kill_wait_spawned_process, spawn_id_get_pid): New procedures.
(spawn_wait_for_attach): Use spawn instead of exec to spawn
processes. Don't map cygwin/windows pids here. Now returns a
spawn id list.
This test fails with --target_board=native-extended-gdbserver because
it misses the usual "disconnect":
(gdb) spawn ../gdbserver/gdbserver --once :2347 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/server-exec-info
Process /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/server-exec-info created; pid = 4736
Listening on port 2347
target extended-remote localhost:2347
Already connected to a remote target. Disconnect? (y or n) ^CsQuit
(gdb) et sysroot remote:
Undefined command: "et". Try "help".
(gdb) n
The program is not being run.
(gdb) FAIL: gdb.server/server-exec-info.exp: set sysroot remote: (got interactive prompt)
info files
(gdb) FAIL: gdb.server/server-exec-info.exp: info files
gdb/testsuite/ChangeLog:
2015-07-28 Pedro Alves <palves@redhat.com>
* gdb.server/server-exec-info.exp: Issue a "disconnect".
My patch series will affect the code starting inferior in GDBserver
(callees of start_inferior), so we need tests to cover how
start_inferior is used in different cases.
In server.c:process_serial_event, start_inferior is used when
GBDserver receives 'R' packet, and this patch is to add a test
for this path, and see how --wrapper option works when the process
is restarted.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* gdb.server/ext-wrapper.exp: Test --wrapper option when
restarting process.
When I run gdb.server/ext-restart.exp, I get the following GDB internal
error,
run^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
Sending packet: $vKill;53c5#3d...Packet received: OK^M
Packet vKill (kill) is supported^M
Sending packet: $vFile:close:6#b6...Packet received: F0^M
Sending packet: $vFile:close:3#b3...Packet received: F0^M
Starting program: /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart ^M
Sending packet: $QDisableRandomization:1#cf...Packet received: OK^M
Sending packet: $R0#82...Sending packet: $qC#b4...Packet received: QCp53c5.53c5^M <-- [1]
Sending packet: $qAttached:53c5#c9...Packet received: E01^M
warning: Remote failure reply: E01^M
....
0x00002aaaaaaac2d0 in ?? () from target:/lib64/ld-linux-x86-64.so.2^M
/home/yao/SourceCode/gnu/gdb/git/gdb/thread.c:88: internal-error: inferior_thread: Assertion `tp' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.server/ext-restart.exp: run to main (GDB internal error)
Resyncing due to internal error.
the test is to restart the program, to make sure GDBserver handles
packet 'R' correctly. From the GDBserver output, we can see,
Remote debugging from host 127.0.0.1^M
Process /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart created; pid = 21445^M
GDBserver restarting^M
Process /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.server/ext-restart created; pid = 21446^M
Killing process(es): 21446
we first start process 21445(0x53c5), kill it and restart a new process
21446. However, in the gdb output above [1], we can see that the reply
of qC is still the old process id rather than the new one. Looks
general_thread isn't up to date after GDBserver receives R packet.
This patch is to update general_thread after call start_inferior.
gdb/gdbserver:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* server.c (process_serial_event): Set general_thread.
gdb/testsuite:
2015-07-24 Yao Qi <yao.qi@linaro.org>
* gdb.server/ext-restart.exp: New file.
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.
Sequential test runs are stopping prematurely like this:
$ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp"
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ...
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ...
can not find channel named "exp6"
while executing
"match_max [match_max -d]"
(procedure "default_gdb_init" line 26)
invoked from within
"default_gdb_init $test_file_name"
(procedure "gdb_init" line 83)
invoked from within
"${tool}_init $test_file_name"
(procedure "runtest" line 18)
invoked from within
"runtest $test_name"
("foreach" body line 42)
invoked from within
...
make[2]: *** [check-single] Error 1
make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make[1]: *** [check] Error 2
make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite'
make: *** [check] Error 2
default_gdb_init has this:
# Unlike most tests, we have a small number of tests that generate
# a very large amount of output. We therefore increase the expect
# buffer size to be able to contain the entire test output. This
# is especially needed by gdb.base/info-macros.exp.
match_max -d 65536
# Also set this value for the currently running GDB.
match_max [match_max -d]
It's the second match_max that is erroring. As that call does not
specify an explicit channel name with -i, expect defaults to
$spawn_id, which is pointing at a channel that is already gone. (If
the spawn_id variable is not set, match_max defaults to
$user_spawn_id / stdin/out).
gdb/testsuite/ChangeLog:
2015-05-08 Pedro Alves <palves@redhat.com>
* gdb.server/non-existing-program.exp: Unset spawn_id.
$ ./gdbserver :1234 blah
Process blah created; pid = 16471
Cannot exec blah: No such file or directory.
Child exited with status 127
Killing process(es): 16471
../../../../src/binutils-gdb/gdb/gdbserver/linux-low.c:920: A problem internal to GDBserver has been detected.
kill_wait_lwp: Assertion `res > 0' failed.
GDBserver shouldn't even be trying to kill that process. GDBserver
kills or detaches from all processes on exit, and due to a missing
mourn_inferior call, GDBserver tries to kill the process that it had
already seen exit.
Tested on x86_64 Fedora 20. New test included. I emulated what
Windows outputs by hacking an error call in linux_create_inferior.
gdb/gdbserver/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* server.c (start_inferior): If the process exits, mourn it.
gdb/testsuite/ChangeLog:
2015-05-06 Pedro Alves <palves@redhat.com>
PR server/18081
* gdb.server/non-existing-program.exp: New file.
This commit modifies remote_add_inferior to take an extra argument
try_open_exec. If this is nonzero, remote_add_inferior will attempt
to open this inferior's executable as the main executable if no main
executable is open already. Callers are updated appropriately.
With this commit, remote debugging can now be initiated using only a
"target remote" or "target extended-remote" command; no "set sysroot"
or "file" commands are required, e.g.
bash$ gdb -q
(gdb) target remote | gdbserver - /bin/sh
Remote debugging using | gdbserver - /bin/sh
Process /bin/sh created; pid = 32166
stdin/stdout redirected
Remote debugging using stdio
Reading symbols from target:/bin/bash...
One testcase required updating as a result of this commit. The test
checked that GDB's "info files" command does not crash if no main
executable is open, and relied on GDB's inability to access the main
executable over the remote protocol. The test was updated to inhibit
this new behavior.
gdb/ChangeLog:
* remote.c (remote_add_inferior): New argument try_open_exec.
If nonzero, attempt to open the inferior's executable file as
the main executable if no main executable is open already.
All callers updated.
* NEWS: Mention that GDB now supports automatic location and
retrieval of executable + files from remote targets.
gdb/doc/ChangeLog:
* gdb.texinfo (Connecting to a Remote Target): Mention that
GDB can access program files from remote targets that support
qXfer:exec-file:read and Host I/O packets.
gdb/testsuite/ChangeLog:
* gdb.server/server-exec-info.exp: Inhibit GDB from accessing
the main executable over the remote protocol.
We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
Nowadays, we are using command "tstatus" to send a packet to GDBserver
in order to check the connection. However, on the target doesn't
support tracepoint, the following error is emitted before sending any
packet to GDBserver.
tstatus^M
Trace can not be run on this target.^M
(gdb) FAIL: gdb.server/server-kill.exp: tstatus
qTStatus is disabled after receiving the empty reply during connecting
to the remote target. When the test executes command "tstatus" again,
remote_get_trace_status returns -1 at the very beginning, and no RSP
packet is sent out.
This patch is to enable qTStatus packet again.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Execute command
"set remote trace-status-packet on" before "tstatus".
Hi,
We see the following fail in the real remote testing...
(gdb) Executing on target: kill -9 29808 (timeout = 300)
spawn [open ...]^M
sh: 1: kill: No such process
The test tries to kill gdbserver in this way:
set server_pid [exp_pid -i [board_info target fileid]]
remote_exec target "kill -9 $server_pid"
in native testing, we'll get the pid of spawned gdbserver, however, in
remote testing, we'll get the pid of ssh session, since we start
gdbserver on the remote target through ssh. The pid on build doesn't
exist on target.
In this patch, we tweak server-kill.c to get the parent pid, which is
the pid of GDBserver. GDB gets it and kill GDBserver on target.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.c: Include sys/types.h and unistd.h.
(main): Call getppid.
* gdb.server/server-kill.exp: Set breakpoint on line "i = 0;"
and continue to it. Read variable "server_pid".
This patch is to remove some lines which looks unnecessary. These
lines were added when server-kill.exp was added. In the version 1,
https://sourceware.org/ml/gdb-patches/2013-03/msg00691.html the test
calls runto_main and delete breakpoint on main,
+if ![runto_main] {
+ return -1
+}
+
+# Otherwise the breakpoint at 'main' would not cause insert
breakpoints during
+# first step.
+delete_breakpoints
However, in the version 2
https://sourceware.org/ml/gdb-patches/2013-03/msg00854.html runto_main
is removed but delete_breakpoints is still there. AFAICS, the line of
delete_breakpoints can be removed too.
gdb/testsuite:
2014-10-11 Yao Qi <yao@codesourcery.com>
* gdb.server/server-kill.exp: Remove "delete_breakpoints".
Several places in the testsuite have a copy of a snippet of code that
spawns a test program, waits a bit, and then does some PID munging for
Cygwin. This is in order to have GDB attach to the spawned program.
This refactors all that to a common procedure.
(multi-attach.exp wants to spawn multiple processes, so this makes the
new procedure's interface work with lists.)
Tested on x86_64 Fedora 20.
gdb/testsuite/ChangeLog:
2014-09-11 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (spawn_wait_for_attach): New procedure.
* gdb.base/attach.exp (do_attach_tests, do_call_attach_tests)
(do_command_attach_tests): Use spawn_wait_for_attach.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
This finally makes background execution commands possible by default.
However, in order to do that, there's one last thing we need to do --
we need to separate the MI and target notions of "async". Unlike the
CLI, where the user explicitly requests foreground vs background
execution in the execution command itself (c vs c&), MI chose to treat
"set target-async" specially -- setting it changes the default
behavior of execution commands.
So, we can't simply "set target-async" default to on, as that would
affect MI frontends. Instead we have to make the setting MI-specific,
and teach MI about sync commands on top of an async target.
Because the "target" word in "set target-async" ends up as a potential
source of confusion, the patch adds a "set mi-async" option, and makes
"set target-async" a deprecated alias.
Rather than make the targets always async, this patch introduces a new
"maint set target-async" option so that the GDB developer can control
whether the target is async. This makes it simpler to debug issues
arising only in the synchronous mode; important because sync mode
seems unlikely to go away.
Unlike in previous revisions, "set target-async" does not affect this
new maint parameter. The rationale for this is that then one can
easily run the test suite in the "maint set target-async off" mode and
have tests that enable mi-async fail just like they fail on
non-async-capable targets. This emulation is exactly the point of the
maint option.
I had asked Tom in a previous iteration to split the actual change of
the target async default to a separate patch, but it turns out that
that is quite awkward in this version of the patch, because with MI
async and target async decoupled (unlike in previous versions), if we
don't flip the default at the same time, then just "set target-async
on" alone never actually manages to do anything. It's best to not
have that transitory state in the tree.
Given "set target-async on" now only has effect for MI, the patch goes
through the testsuite removing it from non-MI tests. MI tests are
adjusted to use the new and less confusing "mi-async" spelling.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* NEWS: Mention "maint set target-async", "set mi-async", and that
background execution commands are now always available.
* target.h (target_async_permitted): Update comment.
* target.c (target_async_permitted, target_async_permitted_1):
Default to 1.
(set_target_async_command): Rename to ...
(maint_set_target_async_command): ... this.
(show_target_async_command): Rename to ...
(maint_show_target_async_command): ... this.
(_initialize_target): Adjust.
* infcmd.c (prepare_execution_command): Make extern.
* inferior.h (prepare_execution_command): Declare.
* infrun.c (set_observer_mode): Leave target async alone.
* mi/mi-interp.c (mi_interpreter_init): Install
mi_on_sync_execution_done as sync_execution_done observer.
(mi_on_sync_execution_done): New function.
(mi_execute_command_input_handler): Don't print the prompt if we
just started a synchronous command with an async target.
(mi_on_resume): Check sync_execution before printing prompt.
* mi/mi-main.h (mi_async_p): Declare.
* mi/mi-main.c: Include gdbcmd.h.
(mi_async_p): New function.
(mi_async, mi_async_1): New globals.
(set_mi_async_command, show_mi_async_command, mi_async): New
functions.
(exec_continue): Call prepare_execution_command.
(run_one_inferior, mi_cmd_exec_run, mi_cmd_list_target_features)
(mi_execute_async_cli_command): Use mi_async_p.
(_initialize_mi_main): Install "set mi-async". Make
"target-async" a deprecated alias.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Non-Stop Mode): Remove "set target-async 1"
from example.
(Asynchronous and non-stop modes): Document '-gdb-set mi-async'.
Mention that target-async is now deprecated.
(Maintenance Commands): Document maint set/show target-async.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.base/async-shell.exp: Don't enable target-async.
* gdb.base/async.exp
* gdb.base/corefile.exp (corefile_test_attach): Remove 'async'
parameter. Adjust.
(top level): Don't test with "target-async".
* gdb.base/dprintf-non-stop.exp: Don't enable target-async.
* gdb.base/gdb-sigterm.exp: Don't test with "target-async".
* gdb.base/inferior-died.exp: Don't enable target-async.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async".
* gdb.mi/mi-nonstop-exit.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-ns-stale-regcache.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-watch-nonstop.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Adjust comment.
* gdb.python/py-evsignal.exp: Don't enable target-async.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.reverse/break-precsave.exp: Don't test with "target-async".
* gdb.server/solib-list.exp: Don't enable target-async.
* gdb.threads/thread-specific-bp.exp: Likewise.
* lib/mi-support.exp: Adjust to use mi-async.
When I run no-thread-db.exp, the breakpoint is set on line 26.
However, the breakpoint is set to line 26 of dl-start.S rather than
no-thread-db.c, which is not intended.
(gdb) monitor set libthread-db-search-path /foo/bar^M
libthread-db-search-path set to `/foo/bar'^M
(gdb) PASS: gdb.server/no-thread-db.exp: libthread-db is now unresolvable
break 26^M
Breakpoint 1 at 0x48018078: file ../sysdeps/powerpc/powerpc32/dl-start.S, line 26.^M
(gdb) continue^M
Continuing.
This patch is to change the breakpoint setting with source file
specified, then it is correct now.
gdb/testsuite:
2014-05-26 Yao Qi <yao@codesourcery.com>
* gdb.server/no-thread-db.exp: Specify source file name
explicitly when setting a breakpoint.
Skip the test on Cygwin too.
2013-09-18 Pedro Alves <palves@redhat.com>
PR server/15967
* gdb.server/wrapper.exp: Also return unsupported for Cygwin, and
change text.
In extended-remote, when GDB connects the target, but target is not
running, the TSVs are not uploaded. When GDB attaches to a process,
the TSVs are not uploaded either. However, GDBserver has some
builtin or predefined TSV to upload, such as $trace_timestamp. This
bug causes $trace_timestamp is never uploaded.
gdb/
2013-06-25 Yao Qi <yao@codesourcery.com>
* remote.c (remote_start_remote): Move code to upload tsv
earlier.
gdb/testsuite/
2013-06-25 Yao Qi <yao@codesourcery.com>
* boards/native-extended-gdbserver.exp: Set board_info
'gdb,predefined_tsv'.
* boards/native-gdbserver.exp: Likewise.
* boards/native-stdio-gdbserver.exp: Likewise.
* gdb.server/ext-attach.exp: Load trace-support.exp. Check
uploaded TSVs if target supports tracing.
* gdb.trace/tsv.exp: Check uploaded TSVs if target supports
tracing and target has predefined tsv.
gdb/doc/
2013-06-25 Yao Qi <yao@codesourcery.com>
* gdbint.texinfo (Testsuite): Document 'gdb,predefined_tsv'.
* exceptions.h (enum errors): New entry TARGET_CLOSE_ERROR.
* remote.c (trace_error): Remove the special handling of '2'.
(readchar) <SERIAL_EOF>
(readchar) <SERIAL_ERROR>
(getpkt_or_notif_sane_1): Use TARGET_CLOSE_ERROR for them.
(remote_get_trace_status): Call throw_exception if EX is
TARGET_CLOSE_ERROR.
* utils.c (perror_with_name): Rename to ...
(throw_perror_with_name): ... here. New parameter errcode, describe it
in the function comment.
(perror_with_name): New function wrapper.
* utils.h (enum errors): New stub declaration.
(throw_perror_with_name): New declaration.
gdb/testsuite/
* gdb.server/server-kill.c: New file.
* gdb.server/server-kill.exp: New file.
null ptr check to prevent gdbserver from crashing
Evaluating a thread local storage variable in a remote scenario crashes
gdbserver if libthread-db could not be loaded.
2013-02-12 Sanimir Agovic <sanimir.agovic@intel.com>
gdbserver/
* thread-db.c (thread_db_get_tls_address):
NULL pointer check thread_db.
testsuite/
* gdb.server/no-thread-db.exp: New file.
* gdb.server/no-thread-db.c: New file.
* gdb.server/Makefile.in (EXECUTABLES): Add no-thread-db.
Maciej W. Rozycki
Sergio Durigan Junior
Pedro Alves
Yao Qi
Joel Brobecker
Luis Machado
Simon Marchi
Gary Benson
Yao Qi
Doug Evans
Tom Tromey
Jan Kratochvil