* [PATCH 0/3] Target remote mode fork and exec support
@ 2015-11-06 23:56 Don Breazeal
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Don Breazeal @ 2015-11-06 23:56 UTC (permalink / raw)
To: gdb-patches
This patchset implements support fork and exec events for target
remote mode Linux targets. This is done primarily by enabling
functionality that had previously been restricted to extended-remote
mode, and by preventing gdbserver from exiting until there are no
more active inferiors left.
There are a number of tests that had to be modified to enable them in
target-remote mode.
The GDB manual sections on connecting to a remote target were modified
and reorganized to clarify the distinction between remote,
extended-remote, and multiprocess, and to collect related information
into subsections.
The patches include:
PATCH 1/3: Implements target remote mode fork and exec event support.
PATCH 2/3: Enables fork and exec tests for target remote mode.
PATCH 3/3: Updates documentation for fork and exec events with target
remote.
Tested on x86_64 Linux with native, remote, and extended-remote. Also
tried it with Pedro's patch that modified gdbserver exit criteria,
https://sourceware.org/ml/gdb-patches/2015-10/msg00222.html, and saw no
regressions.
Thanks, Don
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 3/3] Target remote mode fork and exec docs
2015-11-06 23:56 [PATCH 0/3] Target remote mode fork and exec support Don Breazeal
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
2015-11-06 23:57 ` [PATCH 2/3] Target remote mode fork and exec tests Don Breazeal
@ 2015-11-06 23:57 ` Don Breazeal
2015-11-07 8:18 ` Eli Zaretskii
2 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-11-06 23:57 UTC (permalink / raw)
To: gdb-patches
This patch implements documentation updates for target remote mode
fork and exec events. A summary of the rationale for the changes
made here:
* Connecting to a remote target -- explain that the two protocols exist.
* Connecting in target remote mode -- explain invoking gdbserver for
target remote mode, and move remote-specific text from original
"Connecting to a remote target" section.
* Connecting in target extended-remote mode -- promote this section
from "Using the gdbserver Program | Running gdbserver | Multi-Process Mode
for gdbserver". Put it next to the target remote mode section.
* Host and target files -- collect paragraphs dealing with how to locate
symbol files from original sections "Connecting to a remote target" and
"Using the gdbserver program | Connecting to gdbserver".
* Steps for connecting to a remote target -- used to be "Using the
gdbserver program | Connecting to gdbserver"
* Remote connection commands -- used to be the bulk of "Connecting to a
remote target". Added "target extended-remote" commands and information.
Thanks,
--Don
gdb/
2015-11-06 Don Breazeal <donb@sourceware.org>
* NEWS: Announce fork and exec event support for target remote.
gdb/doc/
2015-11-06 Don Breazeal <donb@sourceware.org>
* gdb.texinfo (Forks): Correct Linux kernel version where
fork and exec events are supported, add notes about support
of these events in target remote mode.
(Connecting): Reorganize and clarify distinctions between
target remote, extended-remote, and multiprocess.
Reorganize related text from separate sections into new
sections. Use @kbd consistently for target commands
instead of @code or @samp.
---
gdb/NEWS | 8 ++
gdb/doc/gdb.texinfo | 212 ++++++++++++++++++++++++++++++++--------------------
2 files changed, 137 insertions(+), 83 deletions(-)
diff --git a/gdb/NEWS b/gdb/NEWS
index b2b1e99..166a6ca 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -87,6 +87,14 @@ set remote exec-event-feature-packet
show remote exec-event-feature-packet
Set/show the use of the remote exec event feature.
+* Target remote mode fork and exec events
+
+ ** GDB now has support for fork and exec events on target remote mode
+ Linux targets. For such targets with Linux kernels 2.5.46 and later,
+ this enables follow-fork-mode, detach-on-fork and fork and exec
+ catchpoints. Note that follow-exec-mode is not supported, because
+ target remote mode does not support the 'run' command.
+
*** Changes in GDB 7.10
* Support for process record-replay and reverse debugging on aarch64*-linux*
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 3c1f785..e364efb 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -3133,10 +3133,11 @@ the child process just like any other process which you attached to.
On some systems, @value{GDBN} provides support for debugging programs that
create additional processes using the @code{fork} or @code{vfork} functions.
Currently, the only platforms with this feature are HP-UX (11.x and later
-only?) and @sc{gnu}/Linux (kernel version 2.5.60 and later).
+only?) and @sc{gnu}/Linux (kernel version 2.5.46 and later).
-The fork debugging commands are supported in both native mode and when
-connected to @code{gdbserver} using @kbd{target extended-remote}.
+The fork debugging commands are supported in native mode and when
+connected to @code{gdbserver} in either @kbd{target remote} mode or
+@kbd{target extended-remote} mode.
By default, when a program forks, @value{GDBN} will continue to debug
the parent process and the child process will run unimpeded.
@@ -3282,6 +3283,11 @@ Program exited normally.
@end table
@end table
+@code{follow-exec-mode} is supported in native mode and
+@kbd{target extended-remote} mode. It has no real effect in
+@kbd{target remote} mode since the run command is not supported in that
+mode.
+
You can use the @code{catch} command to make @value{GDBN} stop whenever
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting Catchpoints}.
@@ -19221,28 +19227,126 @@ configuration of @value{GDBN}; use @code{help target} to list them.
@node Connecting
@section Connecting to a Remote Target
-@value{GDBN} needs an unstripped copy of your program to access symbol
-and debugging information. Some remote targets (@pxref{qXfer
-executable filename read}, and @pxref{Host I/O Packets}) allow
-@value{GDBN} to access program files over the same connection used to
-communicate with @value{GDBN}. With such a target, if the remote
-program is unstripped, the only command you need is @code{target
-remote}. Otherwise, start up @value{GDBN} using the name of the local
+@value{GDBN} supports two types of remote connections, @kbd{target remote}
+mode and @kbd{target extended-remote} mode. There are several major
+differences between the two. In @kbd{target extended-remote} mode, GDB
+stays connected to @code{gdbserver} after the debugged program exits or you
+detach from it, and @code{gdbserver} provides support for the @code{run}
+and @code{attach} commands.
+
+@subsection Connecting in @kbd{target remote} mode
+
+When you invoke @code{gdbserver} for a @kbd{target remote} mode
+session, you must either specify the program to debug or use the
+@option{--attach} option (@pxref{Server,,Running gdbserver}).
+
+Once the connection has been established, you can use all the usual
+@value{GDBN} commands to examine and change data. The remote program
+is already running, so you can use commands like @kbd{step} and
+@kbd{continue}. In @kbd{target remote} mode the @kbd{run} command is
+not supported.
+
+@subsection Connecting in @kbd{target extended-remote} mode
+@cindex @code{gdbserver}, extended-remote mode
+@cindex @code{gdbserver}, exit
+
+When you connect to @code{gdbserver} using @kbd{target remote},
+@code{gdbserver} debugs the specified program only once. When the
+program exits, or you detach from it, @value{GDBN} closes the connection
+and @code{gdbserver} exits.
+
+If you connect using @kbd{target extended-remote}, @code{gdbserver}
+enters extended mode. When the debugged program exits, or you
+detach from it, @value{GDBN} stays connected to @code{gdbserver} even
+though no program is running. The @code{run} and @code{attach}
+commands instruct @code{gdbserver} to run or attach to a new program.
+The @code{run} command uses the value set by @code{set remote exec-file}
+(@pxref{set remote exec-file}) to select the program to run. Command line
+arguments are supported, except for wildcard expansion and I/O
+redirection (@pxref{Arguments}).
+
+@cindex @option{--multi}, @code{gdbserver} option
+To start @code{gdbserver} without supplying an initial command to run
+or process ID to attach, use the @option{--multi} command line option.
+Then you can connect using @kbd{target extended-remote} and start
+the program you want to debug.
+
+In extended mode @code{gdbserver} does not automatically exit unless you
+use the option @option{--once}. You can terminate it by using
+@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note that the
+conditions under which @code{gdbserver} terminates depend on how @value{GDBN}
+connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
+@option{--multi} option to @code{gdbserver} has no influence on that.
+
+@subsection Host and target files
+
+@value{GDBN}, running on the host, needs access to symbol and debugging
+information for your program running on the target. This requires
+access to an unstripped copy of your program, and possibly any associated
+symbol files.
+
+Some remote targets (@pxref{qXfer executable filename read}, and
+@pxref{Host I/O Packets}) allow @value{GDBN} to access program files over
+the same connection used to communicate with @value{GDBN}. With such a
+target, if the remote program is unstripped, the only command you need is
+@kbd{target remote} (or @kbd{target extended-remote}).
+
+If the remote program is stripped, or the target does not support remote
+program file access, start up @value{GDBN} using the name of the local
unstripped copy of your program as the first argument, or use the
-@code{file} command.
+@code{file} command. Use @code{set sysroot} to specify the location (on
+the host) of target libraries (unless your @value{GDBN} was compiled with
+the correct sysroot using @code{--with-sysroot}). Alternatively, you
+may use @code{set solib-search-path} to specify how @value{GDBN} locates
+target libraries.
+
+The symbol file and target libraries must exactly match the executable
+and libraries on the target, with one exception: the files on the host
+system should not be stripped, even if the files on the target system
+are. Mismatched or missing files will lead to confusing results
+during debugging. On @sc{gnu}/Linux targets, mismatched or missing
+files may also prevent @code{gdbserver} from debugging multi-threaded
+programs.
+
+@subsection Steps for connecting to a remote target
+
+The basic procedure for connecting to the remote target is:
+
+@itemize @bullet
+@item
+First, run @value{GDBN} on the host system.
+
+@item
+Next, specify the how @value{GDBN} finds symbol files
+(@pxref{Connecting,,Host and target files}).
+
+@item
+Finally, connect to your target. For TCP connections, you must start up
+@code{gdbserver} prior to using the @kbd{target remote} or
+@kbd{target extended-remote} command. Otherwise you may get an error
+whose text depends on the host system, but which usually looks something
+like @samp{Connection refused}. Don't use the @code{load} command in
+@value{GDBN} when using @code{gdbserver}, since the program is already on
+the target.
+
+@end itemize
+
+@subsection Remote connection commands
-@cindex @code{target remote}
+@cindex @kbd{target remote}
+@cindex @kbd{target extended-remote}
@value{GDBN} can communicate with the target over a serial line, or
over an @acronym{IP} network using @acronym{TCP} or @acronym{UDP}. In
each case, @value{GDBN} uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
-@code{target remote} command establishes a connection to the target.
-Its arguments indicate which medium to use:
+@kbd{target remote} and @kbd{target extended-remote} commands establish
+a connection to the target. Their arguments indicate which medium to use:
@table @code
@item target remote @var{serial-device}
-@cindex serial line, @code{target remote}
+@item target extended-remote @var{serial-device}
+@cindex serial line, @kbd{target remote}
Use @var{serial-device} to communicate with the target. For example,
to use a serial line connected to the device named @file{/dev/ttyb}:
@@ -19253,11 +19357,13 @@ target remote /dev/ttyb
If you're using a serial line, you may want to give @value{GDBN} the
@samp{--baud} option, or use the @code{set serial baud} command
(@pxref{Remote Configuration, set serial baud}) before the
-@code{target} command.
+@kbd{target} command.
@item target remote @code{@var{host}:@var{port}}
@itemx target remote @code{tcp:@var{host}:@var{port}}
-@cindex @acronym{TCP} port, @code{target remote}
+@item target extended-remote @code{@var{host}:@var{port}}
+@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
+@cindex @acronym{TCP} port, @kbd{target remote}
Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
The @var{host} may be either a host name or a numeric @acronym{IP}
address; @var{port} must be a decimal number. The @var{host} could be
@@ -19285,7 +19391,8 @@ target remote :1234
Note that the colon is still required here.
@item target remote @code{udp:@var{host}:@var{port}}
-@cindex @acronym{UDP} port, @code{target remote}
+@item target extended-remote @code{udp:@var{host}:@var{port}}
+@cindex @acronym{UDP} port, @kbd{target remote}
Debug using @acronym{UDP} packets to @var{port} on @var{host}. For example, to
connect to @acronym{UDP} port 2828 on a terminal server named @code{manyfarms}:
@@ -19299,7 +19406,8 @@ can silently drop packets on busy or unreliable networks, which will
cause havoc with your debugging session.
@item target remote | @var{command}
-@cindex pipe, @code{target remote} to
+@item target extended-remote | @var{command}
+@cindex pipe, @kbd{target remote} to
Run @var{command} in the background and communicate with it using a
pipe. The @var{command} is a shell command, to be parsed and expanded
by the system's command shell, @code{/bin/sh}; it should expect remote
@@ -19314,11 +19422,6 @@ program has already exited, this will have no effect.)
@end table
-Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use @kbd{step} and @kbd{continue}, and you do not
-need to use @kbd{run}.
-
@cindex interrupting remote programs
@cindex remote programs, interrupting
Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -19333,7 +19436,7 @@ Give up (and stop debugging it)? (y or n)
@end smallexample
If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
+(If you decide you want to try again later, you can use @kbd{target
remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
goes back to waiting.
@@ -19433,7 +19536,7 @@ target system with the same privileges as the user running
@code{gdbserver}.
@end quotation
-@subsection Running @code{gdbserver}
+@subsection Running gdbserver
@cindex arguments, to @code{gdbserver}
@cindex @code{gdbserver}, command-line arguments
@@ -19526,38 +19629,6 @@ In case more than one copy of @var{program} is running, or @var{program}
has multiple threads, most versions of @code{pidof} support the
@code{-s} option to only return the first process ID.
-@subsubsection Multi-Process Mode for @code{gdbserver}
-@cindex @code{gdbserver}, multiple processes
-@cindex multiple processes with @code{gdbserver}
-
-When you connect to @code{gdbserver} using @code{target remote},
-@code{gdbserver} debugs the specified program only once. When the
-program exits, or you detach from it, @value{GDBN} closes the connection
-and @code{gdbserver} exits.
-
-If you connect using @kbd{target extended-remote}, @code{gdbserver}
-enters multi-process mode. When the debugged program exits, or you
-detach from it, @value{GDBN} stays connected to @code{gdbserver} even
-though no program is running. The @code{run} and @code{attach}
-commands instruct @code{gdbserver} to run or attach to a new program.
-The @code{run} command uses @code{set remote exec-file} (@pxref{set
-remote exec-file}) to select the program to run. Command line
-arguments are supported, except for wildcard expansion and I/O
-redirection (@pxref{Arguments}).
-
-@cindex @option{--multi}, @code{gdbserver} option
-To start @code{gdbserver} without supplying an initial command to run
-or process ID to attach, use the @option{--multi} command line option.
-Then you can connect using @kbd{target extended-remote} and start
-the program you want to debug.
-
-In multi-process mode @code{gdbserver} does not automatically exit unless you
-use the option @option{--once}. You can terminate it by using
-@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note that the
-conditions under which @code{gdbserver} terminates depend on how @value{GDBN}
-connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
-@option{--multi} option to @code{gdbserver} has no influence on that.
-
@subsubsection TCP port allocation lifecycle of @code{gdbserver}
This section applies only when @code{gdbserver} is run to listen on a TCP port.
@@ -19640,31 +19711,6 @@ environment:
$ gdbserver --wrapper env LD_PRELOAD=libtest.so -- :2222 ./testprog
@end smallexample
-@subsection Connecting to @code{gdbserver}
-
-Run @value{GDBN} on the host system.
-
-First make sure you have the necessary symbol files. Load symbols for
-your application using the @code{file} command before you connect. Use
-@code{set sysroot} to locate target libraries (unless your @value{GDBN}
-was compiled with the correct sysroot using @code{--with-sysroot}).
-
-The symbol file and target libraries must exactly match the executable
-and libraries on the target, with one exception: the files on the host
-system should not be stripped, even if the files on the target system
-are. Mismatched or missing files will lead to confusing results
-during debugging. On @sc{gnu}/Linux targets, mismatched or missing
-files may also prevent @code{gdbserver} from debugging multi-threaded
-programs.
-
-Connect to your target (@pxref{Connecting,,Connecting to a Remote Target}).
-For TCP connections, you must start up @code{gdbserver} prior to using
-the @code{target remote} command. Otherwise you may get an error whose
-text depends on the host system, but which usually looks something like
-@samp{Connection refused}. Don't use the @code{load}
-command in @value{GDBN} when using @code{gdbserver}, since the program is
-already on the target.
-
@subsection Monitor Commands for @code{gdbserver}
@cindex monitor commands, for @code{gdbserver}
@anchor{Monitor Commands for gdbserver}
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 1/3] Target remote mode fork and exec events
2015-11-06 23:56 [PATCH 0/3] Target remote mode fork and exec support Don Breazeal
@ 2015-11-06 23:57 ` Don Breazeal
2015-11-20 13:04 ` Pedro Alves
2015-11-06 23:57 ` [PATCH 2/3] Target remote mode fork and exec tests Don Breazeal
2015-11-06 23:57 ` [PATCH 3/3] Target remote mode fork and exec docs Don Breazeal
2 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-11-06 23:57 UTC (permalink / raw)
To: gdb-patches
This patch implements support for fork and exec events with target remote
mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
this enables follow-fork-mode, detach-on-fork and fork and exec
catchpoints. Note that follow-exec-mode is not supported, because target
remote mode does not support the 'run' command.
The changes required to implement this included:
* Don't exit from gdbserver if there are still active inferiors.
* Allow changing the active process in remote mode.
* Enable fork and exec events in remote mode.
* Print "Ending remote debugging" when detaching only if in remote
mode and there is only one inferior left.
(As I write this up I'm concluding that this is incorrect. We
don't care how many active inferiors there are, yes? Perhaps we
need a test that detaches when there are multiple inferiors. I've
added that to my list.)
* Combine remote_kill and extended_remote_kill into a single function
that can handle the multiple inferior case for target remote. Also,
the same thing for remote_mourn and extended_remote_mourn.
* Enable process-style ptids in target remote.
* Remove restriction on multiprocess mode in target remote.
Thanks
--Don
gdb/gdbserver/
2015-11-06 Don Breazeal <donb@sourceware.org>
* server.c (process_serial_event): Don't exit from gdbserver
in remote mode if there are still active inferiors.
gdb/
2015-11-06 Don Breazeal <donb@sourceware.org>
* remote.c (set_general_process): Remove restriction on target
remote mode.
(remote_query_supported): Likewise.
(remote_detach_1): Change restriction to target remote mode to
restriction to last inferior left.
(remote_disconnect): Unpush the target directly instead of
calling remote_mourn.
(remote_kill, extended_remote_kill): Combine functions into one,
remote_kill, and enable extended functionality for target remote.
(remote_mourn, extended_remote_mourn): Combine functions into
one, remote_mourn, and enable extended functionality for target
remote.
(remote_pid_to_str): Enable "process" style ptid string for
target remote.
(remote_supports_multi_process): Remove restriction on target
remote mode.
---
gdb/gdbserver/server.c | 6 +-
gdb/remote.c | 166 ++++++++++++++++++++++++-------------------------
2 files changed, 84 insertions(+), 88 deletions(-)
diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index fd2804b..0f57237 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -3865,9 +3865,11 @@ process_serial_event (void)
discard_queued_stop_replies (pid_to_ptid (pid));
write_ok (own_buf);
- if (extended_protocol)
+ if (extended_protocol || get_first_inferior (&all_threads) != NULL)
{
- /* Treat this like a normal program exit. */
+ /* There is still at least one inferior remaining, so
+ don't terminate gdbserver and treat this like a
+ normal program exit. */
last_status.kind = TARGET_WAITKIND_EXITED;
last_status.value.integer = 0;
last_ptid = pid_to_ptid (pid);
diff --git a/gdb/remote.c b/gdb/remote.c
index fed397a..60da26c 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -123,8 +123,6 @@ static void remote_mourn (struct target_ops *ops);
static void extended_remote_restart (void);
-static void extended_remote_mourn (struct target_ops *);
-
static void remote_send (char **buf, long *sizeof_buf_p);
static int readchar (int timeout);
@@ -2084,7 +2082,7 @@ set_general_process (void)
struct remote_state *rs = get_remote_state ();
/* If the remote can't handle multiple processes, don't bother. */
- if (!rs->extended || !remote_multi_process_p (rs))
+ if (!remote_multi_process_p (rs))
return;
/* We only need to change the remote current thread if it's pointing
@@ -4472,18 +4470,15 @@ remote_query_supported (void)
q = remote_query_supported_append (q, "qRelocInsn+");
- if (rs->extended)
- {
- if (packet_set_cmd_state (PACKET_fork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "fork-events+");
- if (packet_set_cmd_state (PACKET_vfork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "vfork-events+");
- if (packet_set_cmd_state (PACKET_exec_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "exec-events+");
- }
+ if (packet_set_cmd_state (PACKET_fork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "fork-events+");
+ if (packet_set_cmd_state (PACKET_vfork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "vfork-events+");
+ if (packet_set_cmd_state (PACKET_exec_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "exec-events+");
if (packet_set_cmd_state (PACKET_vContSupported) != AUTO_BOOLEAN_FALSE)
q = remote_query_supported_append (q, "vContSupported+");
@@ -4827,7 +4822,8 @@ remote_detach_1 (const char *args, int from_tty)
/* Tell the remote target to detach. */
remote_detach_pid (pid);
- if (from_tty && !rs->extended)
+ /* Exit only if this is the only active inferior. */
+ if (from_tty && !rs->extended && number_of_inferiors () == 1)
puts_filtered (_("Ending remote debugging.\n"));
/* Check to see if we are detaching a fork parent. Note that if we
@@ -4923,10 +4919,11 @@ remote_disconnect (struct target_ops *target, const char *args, int from_tty)
if (args)
error (_("Argument given to \"disconnect\" when remotely debugging."));
- /* Make sure we unpush even the extended remote targets; mourn
- won't do it. So call remote_mourn directly instead of
- target_mourn_inferior. */
- remote_mourn (target);
+ /* Make sure we unpush even the extended remote targets. Calling
+ target_mourn_inferior won't unpush, and remote_mourn won't
+ unpush if there is more than one inferior left. */
+ unpush_target (target);
+ generic_mourn_inferior ();
if (from_tty)
puts_filtered ("Ending remote debugging.\n");
@@ -8562,42 +8559,6 @@ kill_new_fork_children (int pid, struct remote_state *rs)
}
\f
-static void
-remote_kill (struct target_ops *ops)
-{
-
- /* Catch errors so the user can quit from gdb even when we
- aren't on speaking terms with the remote system. */
- TRY
- {
- putpkt ("k");
- }
- CATCH (ex, RETURN_MASK_ERROR)
- {
- if (ex.error == TARGET_CLOSE_ERROR)
- {
- /* If we got an (EOF) error that caused the target
- to go away, then we're done, that's what we wanted.
- "k" is susceptible to cause a premature EOF, given
- that the remote server isn't actually required to
- reply to "k", and it can happen that it doesn't
- even get to reply ACK to the "k". */
- return;
- }
-
- /* Otherwise, something went wrong. We didn't actually kill
- the target. Just propagate the exception, and let the
- user or higher layers decide what to do. */
- throw_exception (ex);
- }
- END_CATCH
-
- /* We've killed the remote end, we get to mourn it. Since this is
- target remote, single-process, mourning the inferior also
- unpushes remote_ops. */
- target_mourn_inferior ();
-}
-
static int
remote_vkill (int pid, struct remote_state *rs)
{
@@ -8624,19 +8585,58 @@ remote_vkill (int pid, struct remote_state *rs)
}
static void
-extended_remote_kill (struct target_ops *ops)
+remote_kill (struct target_ops *ops)
{
int res;
int pid = ptid_get_pid (inferior_ptid);
struct remote_state *rs = get_remote_state ();
+ /* If we are in 'target remote' mode and we are killing the only
+ inferior, then we will tell gdbserver to exit and unpush the
+ target. */
+ if (!rs->extended && number_of_inferiors () <= 1)
+ {
+ /* Catch errors so the user can quit from gdb even when we
+ aren't on speaking terms with the remote system. */
+ TRY
+ {
+ putpkt ("k");
+ }
+ CATCH (ex, RETURN_MASK_ERROR)
+ {
+ if (ex.error == TARGET_CLOSE_ERROR)
+ {
+ /* If we got an (EOF) error that caused the target
+ to go away, then we're done, that's what we wanted.
+ "k" is susceptible to cause a premature EOF, given
+ that the remote server isn't actually required to
+ reply to "k", and it can happen that it doesn't
+ even get to reply ACK to the "k". */
+ return;
+ }
+
+ /* Otherwise, something went wrong. We didn't actually kill
+ the target. Just propagate the exception, and let the
+ user or higher layers decide what to do. */
+ throw_exception (ex);
+ }
+ END_CATCH
+
+ /* We've killed the remote end, we get to mourn it. Since this is
+ target remote, single-process, mourning the inferior also
+ unpushes remote_ops. */
+ target_mourn_inferior ();
+
+ return;
+ }
+
/* If we're stopped while forking and we haven't followed yet, kill the
child task. We need to do this before killing the parent task
because if this is a vfork then the parent will be sleeping. */
kill_new_fork_children (pid, rs);
res = remote_vkill (pid, rs);
- if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
+ if (res == -1 && !(remote_multi_process_p (rs)))
{
/* Don't try 'k' on a multi-process aware stub -- it has no way
to specify the pid. */
@@ -8662,16 +8662,17 @@ extended_remote_kill (struct target_ops *ops)
static void
remote_mourn (struct target_ops *target)
{
- unpush_target (target);
+ struct remote_state *rs = get_remote_state ();
- /* remote_close takes care of doing most of the clean up. */
- generic_mourn_inferior ();
-}
+ /* In 'target remote' mode with one inferior, we shut down gdbserver. */
+ if (!rs->extended && number_of_inferiors () <= 1)
+ {
+ unpush_target (target);
-static void
-extended_remote_mourn (struct target_ops *target)
-{
- struct remote_state *rs = get_remote_state ();
+ /* remote_close takes care of doing most of the clean up. */
+ generic_mourn_inferior ();
+ return;
+ }
/* In case we got here due to an error, but we're going to stay
connected. */
@@ -8702,8 +8703,9 @@ extended_remote_mourn (struct target_ops *target)
current thread. */
record_currthread (rs, minus_one_ptid);
- /* Unlike "target remote", we do not want to unpush the target; then
- the next time the user says "run", we won't be connected. */
+ /* Unlike 'target remote' with no more inferiors, we do not want to
+ unpush the target. If we do then the next time the user says
+ "run", we won't be connected. */
/* Call common code to mark the inferior as not running. */
generic_mourn_inferior ();
@@ -10224,7 +10226,7 @@ remote_pid_to_str (struct target_ops *ops, ptid_t ptid)
{
if (ptid_equal (magic_null_ptid, ptid))
xsnprintf (buf, sizeof buf, "Thread <main>");
- else if (rs->extended && remote_multi_process_p (rs))
+ else if (remote_multi_process_p (rs))
if (ptid_get_lwp (ptid) == 0)
return normal_pid_to_str (ptid);
else
@@ -11398,7 +11400,7 @@ remote_supports_multi_process (struct target_ops *self)
processes, even though plain remote can use the multi-process
thread id extensions, so that GDB knows the target process's
PID. */
- return rs->extended && remote_multi_process_p (rs);
+ return remote_multi_process_p (rs);
}
static int
@@ -12828,6 +12830,14 @@ Specify the serial device it is connected to\n\
remote_ops.to_btrace_conf = remote_btrace_conf;
remote_ops.to_augmented_libraries_svr4_read =
remote_augmented_libraries_svr4_read;
+ remote_ops.to_follow_fork = remote_follow_fork;
+ remote_ops.to_follow_exec = remote_follow_exec;
+ remote_ops.to_insert_fork_catchpoint = remote_insert_fork_catchpoint;
+ remote_ops.to_remove_fork_catchpoint = remote_remove_fork_catchpoint;
+ remote_ops.to_insert_vfork_catchpoint = remote_insert_vfork_catchpoint;
+ remote_ops.to_remove_vfork_catchpoint = remote_remove_vfork_catchpoint;
+ remote_ops.to_insert_exec_catchpoint = remote_insert_exec_catchpoint;
+ remote_ops.to_remove_exec_catchpoint = remote_remove_exec_catchpoint;
}
/* Set up the extended remote vector by making a copy of the standard
@@ -12846,27 +12856,11 @@ init_extended_remote_ops (void)
Specify the serial device it is connected to (e.g. /dev/ttya).";
extended_remote_ops.to_open = extended_remote_open;
extended_remote_ops.to_create_inferior = extended_remote_create_inferior;
- extended_remote_ops.to_mourn_inferior = extended_remote_mourn;
extended_remote_ops.to_detach = extended_remote_detach;
extended_remote_ops.to_attach = extended_remote_attach;
extended_remote_ops.to_post_attach = extended_remote_post_attach;
- extended_remote_ops.to_kill = extended_remote_kill;
extended_remote_ops.to_supports_disable_randomization
= extended_remote_supports_disable_randomization;
- extended_remote_ops.to_follow_fork = remote_follow_fork;
- extended_remote_ops.to_follow_exec = remote_follow_exec;
- extended_remote_ops.to_insert_fork_catchpoint
- = remote_insert_fork_catchpoint;
- extended_remote_ops.to_remove_fork_catchpoint
- = remote_remove_fork_catchpoint;
- extended_remote_ops.to_insert_vfork_catchpoint
- = remote_insert_vfork_catchpoint;
- extended_remote_ops.to_remove_vfork_catchpoint
- = remote_remove_vfork_catchpoint;
- extended_remote_ops.to_insert_exec_catchpoint
- = remote_insert_exec_catchpoint;
- extended_remote_ops.to_remove_exec_catchpoint
- = remote_remove_exec_catchpoint;
}
static int
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 2/3] Target remote mode fork and exec tests
2015-11-06 23:56 [PATCH 0/3] Target remote mode fork and exec support Don Breazeal
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
@ 2015-11-06 23:57 ` Don Breazeal
2015-11-06 23:57 ` [PATCH 3/3] Target remote mode fork and exec docs Don Breazeal
2 siblings, 0 replies; 24+ messages in thread
From: Don Breazeal @ 2015-11-06 23:57 UTC (permalink / raw)
To: gdb-patches
This patch updates tests for fork and exec events in target remote mode.
In the majority of cases this was a simple matter of removing some
code that disabled the test for target remote. In a few cases the
test needed to be disabled; in those cases the gdb_protocol was checked
instead of using the [is_remote target] etc.
In a couple of cases we needed to use clean_restart, since target remote
doesn't support the run command, and in one case we had to modify an
expect expression to allow for a "multiprocess-style" ptid.
Thanks
--Don
gdb/testsuite/
2015-11-06 Don Breazeal <donb@sourceware.org>
* gdb.base/execl-update-breakpoints.exp (main): Enable for target
remote.
* gdb.base/foll-exec-mode.exp (main): Disable for target remote.
* gdb.base/foll-exec.exp (main): Enable for target remote.
* gdb.base/foll-fork.exp (main): Likewise.
* gdb.base/foll-vfork.exp (main): Likewise.
* gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
(proc continue_to_exit_bp_loc): Use clean_restart.
* gdb.base/pie-execl.exp (main): Disable for target remote.
* gdb.base/watch-vfork.exp (main): Enable for target remote.
* gdb.mi/mi-nsthrexec.exp (main): Likewise.
* gdb.threads/execl.exp (main): Likewise.
* gdb.threads/fork-child-threads.exp (main): Likewise.
* gdb.threads/fork-plus-threads.exp (main): Disable for target
remote.
* gdb.threads/fork-thread-pending.exp (main): Enable for target
remote.
* gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
pid.tid style ptids, instead of just tid.
* gdb.threads/thread-execl.exp (main): Enable for target remote.
* gdb.threads/watchpoint-fork.exp (main): Likewise.
---
gdb/testsuite/gdb.base/execl-update-breakpoints.exp | 6 ------
gdb/testsuite/gdb.base/foll-exec-mode.exp | 8 ++++++--
gdb/testsuite/gdb.base/foll-exec.exp | 4 ----
gdb/testsuite/gdb.base/foll-fork.exp | 4 ----
gdb/testsuite/gdb.base/foll-vfork.exp | 4 ----
gdb/testsuite/gdb.base/multi-forks.exp | 6 ++----
gdb/testsuite/gdb.base/pie-execl.exp | 10 ++++++----
gdb/testsuite/gdb.base/watch-vfork.exp | 5 -----
gdb/testsuite/gdb.mi/mi-nsthrexec.exp | 5 -----
gdb/testsuite/gdb.threads/execl.exp | 4 ----
gdb/testsuite/gdb.threads/fork-child-threads.exp | 4 ----
gdb/testsuite/gdb.threads/fork-plus-threads.exp | 8 ++++++++
gdb/testsuite/gdb.threads/fork-thread-pending.exp | 6 ------
gdb/testsuite/gdb.threads/linux-dp.exp | 4 ++--
gdb/testsuite/gdb.threads/thread-execl.exp | 5 -----
gdb/testsuite/gdb.threads/watchpoint-fork.exp | 5 -----
16 files changed, 24 insertions(+), 64 deletions(-)
diff --git a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
index a980791..20d9101 100644
--- a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
+++ b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
@@ -16,12 +16,6 @@
# Test that when following an exec, we don't try to insert breakpoints
# in the new image at the addresses the symbols had before the exec.
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
-}
-
standard_testfile
# Build two copies of the program, each linked at a different address.
diff --git a/gdb/testsuite/gdb.base/foll-exec-mode.exp b/gdb/testsuite/gdb.base/foll-exec-mode.exp
index 3dc44a2..6af6c90 100644
--- a/gdb/testsuite/gdb.base/foll-exec-mode.exp
+++ b/gdb/testsuite/gdb.base/foll-exec-mode.exp
@@ -26,8 +26,12 @@
# be a breakpoint in order to stop after the exec, even if we use
# a single-step command to execute past the exec.
-if { [is_remote target] || ![isnative] } then {
- continue
+# Remote mode doesn't support the 'run' command, which is
+# required for follow-exec-mode testing.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
}
# Until "catch exec" is implemented on other targets...
diff --git a/gdb/testsuite/gdb.base/foll-exec.exp b/gdb/testsuite/gdb.base/foll-exec.exp
index 0a6347c..a36f212 100644
--- a/gdb/testsuite/gdb.base/foll-exec.exp
+++ b/gdb/testsuite/gdb.base/foll-exec.exp
@@ -16,10 +16,6 @@
# This is a test of gdb's ability to follow a process through a
# Unix exec() system call.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "catch exec" is implemented on other targets...
#
if {![istarget "hppa*-hp-hpux*"] && ![istarget "*-linux*"]} then {
diff --git a/gdb/testsuite/gdb.base/foll-fork.exp b/gdb/testsuite/gdb.base/foll-fork.exp
index 0d7c7fd..34a8401 100644
--- a/gdb/testsuite/gdb.base/foll-fork.exp
+++ b/gdb/testsuite/gdb.base/foll-fork.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index 78c5cc8..c82272e 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -18,10 +18,6 @@
# either execs or exits --- since those events take somewhat different
# code paths in GDB, both variants are exercised.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/multi-forks.exp b/gdb/testsuite/gdb.base/multi-forks.exp
index 0582ba4..1663da5 100644
--- a/gdb/testsuite/gdb.base/multi-forks.exp
+++ b/gdb/testsuite/gdb.base/multi-forks.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
@@ -111,6 +107,7 @@ proc continue_to_exit_bp_loc {} {
# First set gdb to follow the child.
# The result should be that each of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork child"
continue_to_exit_bp_loc
@@ -120,6 +117,7 @@ gdb_test "print pids" "\\$.* = \\{0, 0, 0, 0\\}.*" "follow child, print pids"
# Now set gdb to follow the parent.
# Result should be that none of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork parent" ""
continue_to_exit_bp_loc
diff --git a/gdb/testsuite/gdb.base/pie-execl.exp b/gdb/testsuite/gdb.base/pie-execl.exp
index 51edc82..f75c4dc 100644
--- a/gdb/testsuite/gdb.base/pie-execl.exp
+++ b/gdb/testsuite/gdb.base/pie-execl.exp
@@ -23,10 +23,12 @@ if ![istarget *-linux*] {
continue
}
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
+# In remote mode we cannot use the 'set args' command, and this
+# test requires it.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
}
standard_testfile .c
diff --git a/gdb/testsuite/gdb.base/watch-vfork.exp b/gdb/testsuite/gdb.base/watch-vfork.exp
index 9b43ac6..67ff1c2 100644
--- a/gdb/testsuite/gdb.base/watch-vfork.exp
+++ b/gdb/testsuite/gdb.base/watch-vfork.exp
@@ -15,11 +15,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for vfork events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile .c
if { [build_executable ${testfile}.exp ${testfile} $srcfile {debug}] } {
diff --git a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
index 9ba7739..d55a156 100644
--- a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
+++ b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
@@ -18,11 +18,6 @@
# the main thread doesn't just silently stop at the first internal
# breakpoint (usually the _dl_debug_state breakpoint).
-# No exec event support in the remote protocol.
-if { [is_remote target] } then {
- continue
-}
-
if { ![support_displaced_stepping] } {
unsupported "displaced stepping"
return -1
diff --git a/gdb/testsuite/gdb.threads/execl.exp b/gdb/testsuite/gdb.threads/execl.exp
index 66457bd..3855d5d 100644
--- a/gdb/testsuite/gdb.threads/execl.exp
+++ b/gdb/testsuite/gdb.threads/execl.exp
@@ -15,10 +15,6 @@
# Test handling of threads across an execl.
-if { [is_remote target] } then {
- continue
-}
-
# Original image, loads a thread library.
standard_testfile
diff --git a/gdb/testsuite/gdb.threads/fork-child-threads.exp b/gdb/testsuite/gdb.threads/fork-child-threads.exp
index 75e60e1..7c52753 100644
--- a/gdb/testsuite/gdb.threads/fork-child-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-child-threads.exp
@@ -18,10 +18,6 @@ if { ! [istarget "*-*-linux*"] } {
return 0
}
-if { [is_remote target] || ![isnative] } then {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
diff --git a/gdb/testsuite/gdb.threads/fork-plus-threads.exp b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
index 2b34b6c..d5a915b 100644
--- a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
@@ -20,6 +20,14 @@
#
# See https://sourceware.org/bugzilla/show_bug.cgi?id=18600
+# In remote mode, we cannot continue debugging after all
+# inferiors have terminated, and this test requires that.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
+}
+
standard_testfile
proc do_test { detach_on_fork } {
diff --git a/gdb/testsuite/gdb.threads/fork-thread-pending.exp b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
index d229232..ad8adad 100644
--- a/gdb/testsuite/gdb.threads/fork-thread-pending.exp
+++ b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
@@ -13,12 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for `set follow-fork-mode' in the remote
-# protocol.
-if { [is_remote target] } {
- return 0
-}
-
# Only GNU/Linux is known to support `set follow-fork-mode child'.
#
if { ! [istarget "*-*-linux*"] } {
diff --git a/gdb/testsuite/gdb.threads/linux-dp.exp b/gdb/testsuite/gdb.threads/linux-dp.exp
index e612978..486e607 100644
--- a/gdb/testsuite/gdb.threads/linux-dp.exp
+++ b/gdb/testsuite/gdb.threads/linux-dp.exp
@@ -64,7 +64,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
verbose -log "found thread $expect_out(1,string)" 2
lappend threads_before $expect_out(1,string)
exp_continue
@@ -126,7 +126,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
set name $expect_out(1,string)
for {set j 0} {$j != [llength $threads_before] } {incr j} {
if {$name == [lindex $threads_before $j]} {
diff --git a/gdb/testsuite/gdb.threads/thread-execl.exp b/gdb/testsuite/gdb.threads/thread-execl.exp
index a598ad0..8df6a15 100644
--- a/gdb/testsuite/gdb.threads/thread-execl.exp
+++ b/gdb/testsuite/gdb.threads/thread-execl.exp
@@ -16,11 +16,6 @@
# Test that GDB doesn't get stuck when stepping over an exec call done
# by a thread other than the main thread.
-# There's no support for exec events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
diff --git a/gdb/testsuite/gdb.threads/watchpoint-fork.exp b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
index a4557f8..2fd1517 100644
--- a/gdb/testsuite/gdb.threads/watchpoint-fork.exp
+++ b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
@@ -17,11 +17,6 @@
set testfile watchpoint-fork
-if [is_remote target] {
- kfail "remote/13584" "gdbserver does not support debugging across fork"
- return
-}
-
proc test {type symbol} {
with_test_prefix "$type" {
global testfile subdir srcdir gdb_prompt
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-06 23:57 ` [PATCH 3/3] Target remote mode fork and exec docs Don Breazeal
@ 2015-11-07 8:18 ` Eli Zaretskii
2015-11-12 1:00 ` Don Breazeal
2015-11-12 1:00 ` Don Breazeal
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-11-07 8:18 UTC (permalink / raw)
To: Don Breazeal; +Cc: gdb-patches
> From: Don Breazeal <donb@codesourcery.com>
> Date: Fri, 6 Nov 2015 15:56:28 -0800
>
> diff --git a/gdb/NEWS b/gdb/NEWS
> index b2b1e99..166a6ca 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -87,6 +87,14 @@ set remote exec-event-feature-packet
> show remote exec-event-feature-packet
> Set/show the use of the remote exec event feature.
>
> +* Target remote mode fork and exec events
> +
> + ** GDB now has support for fork and exec events on target remote mode
> + Linux targets. For such targets with Linux kernels 2.5.46 and later,
> + this enables follow-fork-mode, detach-on-fork and fork and exec
> + catchpoints. Note that follow-exec-mode is not supported, because
> + target remote mode does not support the 'run' command.
> +
> *** Changes in GDB 7.10
This part is OK.
> -@value{GDBN} needs an unstripped copy of your program to access symbol
> -and debugging information. Some remote targets (@pxref{qXfer
> -executable filename read}, and @pxref{Host I/O Packets}) allow
> -@value{GDBN} to access program files over the same connection used to
> -communicate with @value{GDBN}. With such a target, if the remote
> -program is unstripped, the only command you need is @code{target
> -remote}. Otherwise, start up @value{GDBN} using the name of the local
> +@value{GDBN} supports two types of remote connections, @kbd{target remote}
> +mode and @kbd{target extended-remote} mode. There are several major
> +differences between the two. In @kbd{target extended-remote} mode, GDB
^^^
@value{GDBN}
> +stays connected to @code{gdbserver} after the debugged program exits or you
> +detach from it, and @code{gdbserver} provides support for the @code{run}
> +and @code{attach} commands.
Saying "several major differences" and then neither describing them
nor providing a reference (not even just "described below") will leave
the reader confused, I think. How about a short summary of the
differences, e.g. as an itemized list, here?
Also, does the sentence that follow (the last one in the above
excerpt) need to be here? It reads strange, especially since it
doesn't seem like it belongs to the aforementioned differences. Maybe
you could reword it so it did contrast the two modes.
Alternatively, perhaps the following subsections are better rearranged
as extended descriptions of each of the differences, e.g. using @table.
Right now, they read somewhat confusingly, because the description
jumps between the two modes without providing any intermediate summary
for the reader, and thus it is easy to become confused as to what mode
and what difference you are describing. Some better organization of
the same material could help the reader organize their thoughts and
come out with a better understanding of the differences.
Last, but not least: please consider adding @cindex entries to each of
the subsections, with text that describes the main subject of each
subsection. In many cases, just the down-cased name of the section is
a good starting point. This will help the readers find the subsection
quickly using the Info index-searching commands, which is important
for using the manual as a reference.
> +@item
> +Finally, connect to your target. For TCP connections, you must start up
> +@code{gdbserver} prior to using the @kbd{target remote} or
> +@kbd{target extended-remote} command. Otherwise you may get an error
> +whose text depends on the host system, but which usually looks something
> +like @samp{Connection refused}. Don't use the @code{load} command in
> +@value{GDBN} when using @code{gdbserver}, since the program is already on
> +the target.
There's some inconsistency in your usage of @code and @kbd markup for
commands. In general, the correct markup is @kbd when the context is
about commands typed by the user, and @code otherwise. (The GDB
manual almost never uses @kbd, for historical reasons, btw.) You have
changed some of the @code to @kbd regardless of context, or so it
seems. But in the above passage, you use @code as well, so I'm unsure
what is your rule for selecting one or the other.
> @item target remote @var{serial-device}
> -@cindex serial line, @code{target remote}
> +@item target extended-remote @var{serial-device}
^^^^^
Should be @itemx.
> @item target remote @code{udp:@var{host}:@var{port}}
> -@cindex @acronym{UDP} port, @code{target remote}
> +@item target extended-remote @code{udp:@var{host}:@var{port}}
Likewise.
> @item target remote | @var{command}
> -@cindex pipe, @code{target remote} to
> +@item target extended-remote | @var{command}
Likewise.
> -@subsection Running @code{gdbserver}
> +@subsection Running gdbserver
Not sure why you removed the markup from "gdbserver" here.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-07 8:18 ` Eli Zaretskii
@ 2015-11-12 1:00 ` Don Breazeal
2015-11-12 1:00 ` Don Breazeal
1 sibling, 0 replies; 24+ messages in thread
From: Don Breazeal @ 2015-11-12 1:00 UTC (permalink / raw)
To: eliz, gdb-patches
Hi Eli,
Thanks for the review.
On 11/7/2015 12:18 AM, Eli Zaretskii wrote:
>> From: Don Breazeal <donb@codesourcery.com>
>> Date: Fri, 6 Nov 2015 15:56:28 -0800
>>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index b2b1e99..166a6ca 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -87,6 +87,14 @@ set remote exec-event-feature-packet
>> show remote exec-event-feature-packet
>> Set/show the use of the remote exec event feature.
>>
>> +* Target remote mode fork and exec events
>> +
>> + ** GDB now has support for fork and exec events on target remote mode
>> + Linux targets. For such targets with Linux kernels 2.5.46 and later,
>> + this enables follow-fork-mode, detach-on-fork and fork and exec
>> + catchpoints. Note that follow-exec-mode is not supported, because
>> + target remote mode does not support the 'run' command.
>> +
>> *** Changes in GDB 7.10
>
> This part is OK.
>
>> -@value{GDBN} needs an unstripped copy of your program to access symbol
>> -and debugging information. Some remote targets (@pxref{qXfer
>> -executable filename read}, and @pxref{Host I/O Packets}) allow
>> -@value{GDBN} to access program files over the same connection used to
>> -communicate with @value{GDBN}. With such a target, if the remote
>> -program is unstripped, the only command you need is @code{target
>> -remote}. Otherwise, start up @value{GDBN} using the name of the local
>> +@value{GDBN} supports two types of remote connections, @kbd{target remote}
>> +mode and @kbd{target extended-remote} mode. There are several major
>> +differences between the two. In @kbd{target extended-remote} mode, GDB
> ^^^
> @value{GDBN}
>
>> +stays connected to @code{gdbserver} after the debugged program exits or you
>> +detach from it, and @code{gdbserver} provides support for the @code{run}
>> +and @code{attach} commands.
>
> Saying "several major differences" and then neither describing them
> nor providing a reference (not even just "described below") will leave
> the reader confused, I think. How about a short summary of the
> differences, e.g. as an itemized list, here?
>
> Also, does the sentence that follow (the last one in the above
> excerpt) need to be here? It reads strange, especially since it
> doesn't seem like it belongs to the aforementioned differences. Maybe
> you could reword it so it did contrast the two modes.
>
> Alternatively, perhaps the following subsections are better rearranged
> as extended descriptions of each of the differences, e.g. using @table.
> Right now, they read somewhat confusingly, because the description
> jumps between the two modes without providing any intermediate summary
> for the reader, and thus it is easy to become confused as to what mode
> and what difference you are describing. Some better organization of
> the same material could help the reader organize their thoughts and
> come out with a better understanding of the differences.
I went with the latter suggestion. I hope my interpretation of this
doesn't violate any doc conventions. In the previous version I had
tried to leave some paragraphs unmodified, just reorganizing where
they were. I've been more liberal in my changes in this version.
>
> Last, but not least: please consider adding @cindex entries to each of
> the subsections, with text that describes the main subject of each
> subsection. In many cases, just the down-cased name of the section is
> a good starting point. This will help the readers find the subsection
> quickly using the Info index-searching commands, which is important
> for using the manual as a reference.
I added a number of these.
>
>> +@item
>> +Finally, connect to your target. For TCP connections, you must start up
>> +@code{gdbserver} prior to using the @kbd{target remote} or
>> +@kbd{target extended-remote} command. Otherwise you may get an error
>> +whose text depends on the host system, but which usually looks something
>> +like @samp{Connection refused}. Don't use the @code{load} command in
>> +@value{GDBN} when using @code{gdbserver}, since the program is already on
>> +the target.
>
> There's some inconsistency in your usage of @code and @kbd markup for
> commands. In general, the correct markup is @kbd when the context is
> about commands typed by the user, and @code otherwise. (The GDB
> manual almost never uses @kbd, for historical reasons, btw.) You have
> changed some of the @code to @kbd regardless of context, or so it
> seems. But in the above passage, you use @code as well, so I'm unsure
> what is your rule for selecting one or the other.
I misunderstood the convention here. Thanks for clarifying. I think I
have more-or-less restored things. Basically, as I understand it, the rule
is: use @kbd where the sentence is saying "type @kbd{foo}" or "use
@kbd{foo}", but use @code if it is just referring to it, like "in the
case of the @code{foo} command".
>
>> @item target remote @var{serial-device}
>> -@cindex serial line, @code{target remote}
>> +@item target extended-remote @var{serial-device}
> ^^^^^
> Should be @itemx.
I fixed all of these.
>> -@subsection Running @code{gdbserver}
>> +@subsection Running gdbserver
>
> Not sure why you removed the markup from "gdbserver" here.
My ignorance about how to implement cross-references. I've figured out
the right thing to do, and restored the markup.
Let me know what you think about this version.
thanks
--Don
-----------------------
This patch implements documentation updates for target remote mode
fork and exec events. A summary of the rationale for the changes
made here:
* Types of Remote Connections -- explain that the two protocols exist,
and describe the differences between the two.
* Host and Target Files -- collect paragraphs dealing with how to locate
symbol files from original sections "Connecting to a remote target" and
"Using the gdbserver program | Connecting to gdbserver".
* Remote connection commands -- used to be the bulk of "Connecting to a
remote target". Added "target extended-remote" commands and information.
* Multi-Process Mode for gdbserver -- delete section, move information
to "Types of Remote Connections".
* Other assorted cleanups, @cindex entries, @anchor and @pxref entries.
Thanks,
--Don
gdb/
2015-11-11 Don Breazeal <donb@sourceware.org>
* NEWS: Announce fork and exec event support for target remote.
gdb/doc/
2015-11-11 Don Breazeal <donb@sourceware.org>
* gdb.texinfo (Forks): Correct Linux kernel version where
fork and exec events are supported, add notes about support
of these events in target remote mode.
(Connecting): Reorganize and clarify distinctions between
target remote, extended-remote, and multiprocess.
Reorganize related text from separate sections into new
sections.
(Server): Note effects of target extended-remote mode.
Delete section on Multi-Process Mode for gdbserver.
Move some text to "Connecting" node.
---
gdb/NEWS | 8 ++
gdb/doc/gdb.texinfo | 270 +++++++++++++++++++++++++++++++++++++---------------
2 files changed, 201 insertions(+), 77 deletions(-)
diff --git a/gdb/NEWS b/gdb/NEWS
index b2b1e99..166a6ca 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -87,6 +87,14 @@ set remote exec-event-feature-packet
show remote exec-event-feature-packet
Set/show the use of the remote exec event feature.
+* Target remote mode fork and exec events
+
+ ** GDB now has support for fork and exec events on target remote mode
+ Linux targets. For such targets with Linux kernels 2.5.46 and later,
+ this enables follow-fork-mode, detach-on-fork and fork and exec
+ catchpoints. Note that follow-exec-mode is not supported, because
+ target remote mode does not support the 'run' command.
+
*** Changes in GDB 7.10
* Support for process record-replay and reverse debugging on aarch64*-linux*
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 3c1f785..c06e95d 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -3133,10 +3133,11 @@ the child process just like any other process which you attached to.
On some systems, @value{GDBN} provides support for debugging programs that
create additional processes using the @code{fork} or @code{vfork} functions.
Currently, the only platforms with this feature are HP-UX (11.x and later
-only?) and @sc{gnu}/Linux (kernel version 2.5.60 and later).
+only?) and @sc{gnu}/Linux (kernel version 2.5.46 and later).
-The fork debugging commands are supported in both native mode and when
-connected to @code{gdbserver} using @kbd{target extended-remote}.
+The fork debugging commands are supported in native mode and when
+connected to @code{gdbserver} in either @code{target remote} mode or
+@code{target extended-remote} mode.
By default, when a program forks, @value{GDBN} will continue to debug
the parent process and the child process will run unimpeded.
@@ -3282,6 +3283,11 @@ Program exited normally.
@end table
@end table
+@code{follow-exec-mode} is supported in native mode and
+@code{target extended-remote} mode. It has no real effect in
+@code{target remote} mode since the run command is not supported in that
+mode.
+
You can use the @code{catch} command to make @value{GDBN} stop whenever
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting Catchpoints}.
@@ -19220,28 +19226,150 @@ configuration of @value{GDBN}; use @code{help target} to list them.
@node Connecting
@section Connecting to a Remote Target
+@cindex remote debugging, connecting
+@cindex @code{gdbserver}, connecting
+@cindex remote debugging, types of connections
+@cindex @code{gdbserver}, types of connections
+@cindex @code{gdbserver}, @code{target remote} mode
+@cindex @code{gdbserver}, @code{target extended-remote} mode
+
+This section describes how to connect to a remote target, including the
+types of connections and their differences, how to set up executable and
+symbol files on the host and target, and the commands used for
+connecting to and disconnecting from the remote target.
+
+@subsection Types of Remote Connections
+
+@value{GDBN} supports two types of remote connections, @code{target remote}
+mode and @code{target extended-remote} mode. Note that many remote targets
+support only @code{target remote} mode. There are several major
+differences between the two types of connections, enumerated here:
+
+@table @asis
+
+@cindex remote debugging, detach and program exit
+@item Result of detach or program exit
+
+@strong{target remote mode:} When the debugged program exits or you
+detach from it, @value{GDBN} disconnects from the target. When using
+@code{gdbserver}, @code{gdbserver} will exit.
+
+@strong{target extended-remote mode:} When the debugged program exits or
+you detach from it, @value{GDBN} remains connected to the target, even
+though no program is running. You can rerun the program, attach to a
+running program, or use @code{monitor} commands specific to the target.
+
+When using @code{gdbserver} in this case, it does not exit unless it was
+invoked using the @option{--once} option. If the @option{--once} option
+was not used, you can ask @code{gdbserver} to exit using the
+@code{monitor exit} command (@pxref{Monitor Commands for gdbserver}).
+
+@item Specifying the program to debug
+
+For both connection types you use the @code{file} command to specify the
+program on the host system. If you are using @code{gdbserver} there are
+some differences in how to specify the location of the program on the
+target.
+
+@strong{target remote mode:} You must either specify the program to debug
+on the @code{gdbserver} command line or use the @option{--attach} option
+(@pxref{Attaching to a program,,Attaching to a Running Program}).
+
+@cindex @option{--multi}, @code{gdbserver} option
+@strong{target extended-remote mode:} You may specify the program to debug
+on the @code{gdbserver} command line, or you can load the program or attach
+to it using @value{GDBN} commands after connecting to @code{gdbserver}.
+
+@anchor{Types of Remote Connnections: --multi option}
+You can start @code{gdbserver} without supplying an initial command to run
+or process ID to attach. To do this, use the @option{--multi} command line
+option. Then you can connect using @code{target extended-remote} and start
+the program you want to debug (see below for details on using the
+@code{run} command in this scenario). Note that the conditions under which
+@code{gdbserver} terminates depend on how @value{GDBN} connects to it
+(@code{target remote} or @code{target extended-remote}). The
+@option{--multi} option to @code{gdbserver} has no influence on that.
-@value{GDBN} needs an unstripped copy of your program to access symbol
-and debugging information. Some remote targets (@pxref{qXfer
-executable filename read}, and @pxref{Host I/O Packets}) allow
-@value{GDBN} to access program files over the same connection used to
-communicate with @value{GDBN}. With such a target, if the remote
-program is unstripped, the only command you need is @code{target
-remote}. Otherwise, start up @value{GDBN} using the name of the local
+@item The @code{run} command
+@strong{target remote mode:} The @code{run} command is not supported.
+Once a connection has been established, you can use all the usual
+@value{GDBN} commands to examine and change data. The remote program
+is already running, so you can use commands like @kbd{step} and
+@kbd{continue}.
+
+@strong{target extended-remote mode:} The @code{run} command is supported.
+The @code{run} command uses the value set by @code{set remote exec-file}
+(@pxref{set remote exec-file}) to select the program to run. Command line
+arguments are supported, except for wildcard expansion and I/O
+redirection (@pxref{Arguments}).
+
+If you specify the program to debug on the command line, then the
+@code{run} command is not required to start execution, and you can
+resume using commands like @kbd{step} and @kbd{continue} as with
+@code{target remote} mode.
+
+@anchor{Types of Remote Connections: Attaching}
+@item Attaching
+@strong{target remote mode:} The @value{GDBN} command @code{attach} is
+not supported. To attach to a running program using @code{gdbserver}, you
+must use the @option{--attach} option (@pxref{Running gdbserver}).
+
+@strong{target extended-remote mode:} To attach to a running program,
+you may use the @code{attach} command after the connection has been
+established. If you are using @code{gdbserver}, you may also invoke
+@code{gdbserver} using the @option{--attach} option
+(@pxref{Running gdbserver}).
+
+@end table
+
+@anchor{Host and target files}
+@subsection Host and Target Files
+@cindex remote debugging, symbol files
+@cindex symbol files, remote debugging
+
+@value{GDBN}, running on the host, needs access to symbol and debugging
+information for your program running on the target. This requires
+access to an unstripped copy of your program, and possibly any associated
+symbol files. Note that this section applies equally to both @code{target
+remote} mode and @code{target extended-remote} mode.
+
+Some remote targets (@pxref{qXfer executable filename read}, and
+@pxref{Host I/O Packets}) allow @value{GDBN} to access program files over
+the same connection used to communicate with @value{GDBN}. With such a
+target, if the remote program is unstripped, the only command you need is
+@code{target remote} (or @code{target extended-remote}).
+
+If the remote program is stripped, or the target does not support remote
+program file access, start up @value{GDBN} using the name of the local
unstripped copy of your program as the first argument, or use the
-@code{file} command.
+@code{file} command. Use @code{set sysroot} to specify the location (on
+the host) of target libraries (unless your @value{GDBN} was compiled with
+the correct sysroot using @code{--with-sysroot}). Alternatively, you
+may use @code{set solib-search-path} to specify how @value{GDBN} locates
+target libraries.
+
+The symbol file and target libraries must exactly match the executable
+and libraries on the target, with one exception: the files on the host
+system should not be stripped, even if the files on the target system
+are. Mismatched or missing files will lead to confusing results
+during debugging. On @sc{gnu}/Linux targets, mismatched or missing
+files may also prevent @code{gdbserver} from debugging multi-threaded
+programs.
-@cindex @code{target remote}
+@subsection Remote Connection Commands
+@cindex remote connection commands
@value{GDBN} can communicate with the target over a serial line, or
over an @acronym{IP} network using @acronym{TCP} or @acronym{UDP}. In
each case, @value{GDBN} uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
-@code{target remote} command establishes a connection to the target.
-Its arguments indicate which medium to use:
+@code{target remote} and @code{target extended-remote} commands
+establish a connection to the target. Both commands accept the same
+arguments, which indicate the medium to use:
@table @code
@item target remote @var{serial-device}
+@itemx target extended-remote @var{serial-device}
@cindex serial line, @code{target remote}
Use @var{serial-device} to communicate with the target. For example,
to use a serial line connected to the device named @file{/dev/ttyb}:
@@ -19257,6 +19385,8 @@ If you're using a serial line, you may want to give @value{GDBN} the
@item target remote @code{@var{host}:@var{port}}
@itemx target remote @code{tcp:@var{host}:@var{port}}
+@itemx target extended-remote @code{@var{host}:@var{port}}
+@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
@cindex @acronym{TCP} port, @code{target remote}
Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
The @var{host} may be either a host name or a numeric @acronym{IP}
@@ -19285,6 +19415,7 @@ target remote :1234
Note that the colon is still required here.
@item target remote @code{udp:@var{host}:@var{port}}
+@itemx target extended-remote @code{udp:@var{host}:@var{port}}
@cindex @acronym{UDP} port, @code{target remote}
Debug using @acronym{UDP} packets to @var{port} on @var{host}. For example, to
connect to @acronym{UDP} port 2828 on a terminal server named @code{manyfarms}:
@@ -19299,6 +19430,7 @@ can silently drop packets on busy or unreliable networks, which will
cause havoc with your debugging session.
@item target remote | @var{command}
+@itemx target extended-remote | @var{command}
@cindex pipe, @code{target remote} to
Run @var{command} in the background and communicate with it using a
pipe. The @var{command} is a shell command, to be parsed and expanded
@@ -19314,11 +19446,6 @@ program has already exited, this will have no effect.)
@end table
-Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use @kbd{step} and @kbd{continue}, and you do not
-need to use @kbd{run}.
-
@cindex interrupting remote programs
@cindex remote programs, interrupting
Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -19332,10 +19459,13 @@ Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n)
@end smallexample
-If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
-remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
-goes back to waiting.
+In @code{target remote} mode, if you type @kbd{y}, @value{GDBN} abandons
+the remote debugging session. (If you decide you want to try again later,
+you can use @kbd{target remote} again to connect once more.) If you type
+@kbd{n}, @value{GDBN} goes back to waiting.
+
+In @code{target extended-remote} mode, typing @kbd{n} will leave
+@value{GDBN} connected to the target.
@table @code
@kindex detach (remote)
@@ -19344,11 +19474,13 @@ When you have finished debugging the remote program, you can use the
@code{detach} command to release it from @value{GDBN} control.
Detaching from the target normally resumes its execution, but the results
will depend on your particular remote stub. After the @code{detach}
-command, @value{GDBN} is free to connect to another target.
+command in @code{target remote} mode, @value{GDBN} is free to connect to
+another target. In @code{target extended-remote} mode, @value{GDBN} is
+still connected to the target.
@kindex disconnect
@item disconnect
-The @code{disconnect} command behaves like @code{detach}, except that
+The @code{disconnect} command closes the connection to the target, and
the target is generally not resumed. It will wait for @value{GDBN}
(this instance or another one) to connect and continue debugging. After
the @code{disconnect} command, @value{GDBN} is again free to connect to
@@ -19405,7 +19537,8 @@ Delete @var{targetfile} from the target system.
@cindex remote connection without stubs
@code{gdbserver} is a control program for Unix-like systems, which
allows you to connect your program with a remote @value{GDBN} via
-@code{target remote}---but without linking in the usual debugging stub.
+@code{target remote} or @code{target extended-remote}---but without
+linking in the usual debugging stub.
@code{gdbserver} is not a complete replacement for the debugging stubs,
because it requires essentially the same operating-system facilities
@@ -19433,6 +19566,7 @@ target system with the same privileges as the user running
@code{gdbserver}.
@end quotation
+@anchor{Running gdbserver}
@subsection Running @code{gdbserver}
@cindex arguments, to @code{gdbserver}
@cindex @code{gdbserver}, command-line arguments
@@ -19500,6 +19634,7 @@ Programs started with stdio-connected gdbserver have @file{/dev/null} for
display through a pipe connected to gdbserver.
Both @code{stdout} and @code{stderr} use the same pipe.
+@anchor{Attaching to a program}
@subsubsection Attaching to a Running Program
@cindex attach to a program, @code{gdbserver}
@cindex @option{--attach}, @code{gdbserver} option
@@ -19511,8 +19646,12 @@ This is accomplished via the @code{--attach} argument. The syntax is:
target> gdbserver --attach @var{comm} @var{pid}
@end smallexample
-@var{pid} is the process ID of a currently running process. It isn't necessary
-to point @code{gdbserver} at a binary for the running process.
+@var{pid} is the process ID of a currently running process. It isn't
+necessary to point @code{gdbserver} at a binary for the running process.
+
+In @code{target extended-remote} mode, you can also attach using the
+@value{GDBN} attach command
+(@pxref{Types of Remote Connections: Attaching}).
@pindex pidof
You can debug processes by name instead of process ID if your target has the
@@ -19526,41 +19665,10 @@ In case more than one copy of @var{program} is running, or @var{program}
has multiple threads, most versions of @code{pidof} support the
@code{-s} option to only return the first process ID.
-@subsubsection Multi-Process Mode for @code{gdbserver}
-@cindex @code{gdbserver}, multiple processes
-@cindex multiple processes with @code{gdbserver}
-
-When you connect to @code{gdbserver} using @code{target remote},
-@code{gdbserver} debugs the specified program only once. When the
-program exits, or you detach from it, @value{GDBN} closes the connection
-and @code{gdbserver} exits.
-
-If you connect using @kbd{target extended-remote}, @code{gdbserver}
-enters multi-process mode. When the debugged program exits, or you
-detach from it, @value{GDBN} stays connected to @code{gdbserver} even
-though no program is running. The @code{run} and @code{attach}
-commands instruct @code{gdbserver} to run or attach to a new program.
-The @code{run} command uses @code{set remote exec-file} (@pxref{set
-remote exec-file}) to select the program to run. Command line
-arguments are supported, except for wildcard expansion and I/O
-redirection (@pxref{Arguments}).
-
-@cindex @option{--multi}, @code{gdbserver} option
-To start @code{gdbserver} without supplying an initial command to run
-or process ID to attach, use the @option{--multi} command line option.
-Then you can connect using @kbd{target extended-remote} and start
-the program you want to debug.
-
-In multi-process mode @code{gdbserver} does not automatically exit unless you
-use the option @option{--once}. You can terminate it by using
-@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note that the
-conditions under which @code{gdbserver} terminates depend on how @value{GDBN}
-connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
-@option{--multi} option to @code{gdbserver} has no influence on that.
-
@subsubsection TCP port allocation lifecycle of @code{gdbserver}
-This section applies only when @code{gdbserver} is run to listen on a TCP port.
+This section applies only when @code{gdbserver} is run to listen on a TCP
+port.
@code{gdbserver} normally terminates after all of its debugged processes have
terminated in @kbd{target remote} mode. On the other hand, for @kbd{target
@@ -19591,6 +19699,12 @@ instance closes its port after the first connection.
@anchor{Other Command-Line Arguments for gdbserver}
@subsubsection Other Command-Line Arguments for @code{gdbserver}
+You can use the @option{--multi} option to start @code{gdbserver} without
+specifying a program to debug or a process to attach to. Then you can
+attach in @code{target extended-remote} mode and run or attach to a
+program. For more information,
+@pxref{Types of Remote Connnections: --multi option}.
+
@cindex @option{--debug}, @code{gdbserver} option
The @option{--debug} option tells @code{gdbserver} to display extra
status information about the debugging process.
@@ -19642,32 +19756,34 @@ $ gdbserver --wrapper env LD_PRELOAD=libtest.so -- :2222 ./testprog
@subsection Connecting to @code{gdbserver}
-Run @value{GDBN} on the host system.
+The basic procedure for connecting to the remote target is:
+@itemize
-First make sure you have the necessary symbol files. Load symbols for
-your application using the @code{file} command before you connect. Use
-@code{set sysroot} to locate target libraries (unless your @value{GDBN}
-was compiled with the correct sysroot using @code{--with-sysroot}).
+@item
+Run @value{GDBN} on the host system.
-The symbol file and target libraries must exactly match the executable
-and libraries on the target, with one exception: the files on the host
-system should not be stripped, even if the files on the target system
-are. Mismatched or missing files will lead to confusing results
-during debugging. On @sc{gnu}/Linux targets, mismatched or missing
-files may also prevent @code{gdbserver} from debugging multi-threaded
-programs.
+@item
+Make sure you have the necessary symbol files
+(@pxref{Host and target files}).
+Load symbols for your application using the @code{file} command before you
+connect. Use @code{set sysroot} to locate target libraries (unless your
+@value{GDBN} was compiled with the correct sysroot using
+@code{--with-sysroot}).
+@item
Connect to your target (@pxref{Connecting,,Connecting to a Remote Target}).
For TCP connections, you must start up @code{gdbserver} prior to using
-the @code{target remote} command. Otherwise you may get an error whose
+the @code{target} command. Otherwise you may get an error whose
text depends on the host system, but which usually looks something like
@samp{Connection refused}. Don't use the @code{load}
-command in @value{GDBN} when using @code{gdbserver}, since the program is
-already on the target.
+command in @value{GDBN} when using @code{target remote} mode, since the
+program is already on the target.
+@end itemize
+
+@anchor{Monitor Commands for gdbserver}
@subsection Monitor Commands for @code{gdbserver}
@cindex monitor commands, for @code{gdbserver}
-@anchor{Monitor Commands for gdbserver}
During a @value{GDBN} session using @code{gdbserver}, you can use the
@code{monitor} command to send special requests to @code{gdbserver}.
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-07 8:18 ` Eli Zaretskii
2015-11-12 1:00 ` Don Breazeal
@ 2015-11-12 1:00 ` Don Breazeal
2015-11-12 16:48 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-11-12 1:00 UTC (permalink / raw)
To: eliz, gdb-patches
Hi Eli,
Thanks for the review.
On 11/7/2015 12:18 AM, Eli Zaretskii wrote:
>> From: Don Breazeal <donb@codesourcery.com>
>> Date: Fri, 6 Nov 2015 15:56:28 -0800
>>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index b2b1e99..166a6ca 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -87,6 +87,14 @@ set remote exec-event-feature-packet
>> show remote exec-event-feature-packet
>> Set/show the use of the remote exec event feature.
>>
>> +* Target remote mode fork and exec events
>> +
>> + ** GDB now has support for fork and exec events on target remote mode
>> + Linux targets. For such targets with Linux kernels 2.5.46 and later,
>> + this enables follow-fork-mode, detach-on-fork and fork and exec
>> + catchpoints. Note that follow-exec-mode is not supported, because
>> + target remote mode does not support the 'run' command.
>> +
>> *** Changes in GDB 7.10
>
> This part is OK.
>
>> -@value{GDBN} needs an unstripped copy of your program to access symbol
>> -and debugging information. Some remote targets (@pxref{qXfer
>> -executable filename read}, and @pxref{Host I/O Packets}) allow
>> -@value{GDBN} to access program files over the same connection used to
>> -communicate with @value{GDBN}. With such a target, if the remote
>> -program is unstripped, the only command you need is @code{target
>> -remote}. Otherwise, start up @value{GDBN} using the name of the local
>> +@value{GDBN} supports two types of remote connections, @kbd{target remote}
>> +mode and @kbd{target extended-remote} mode. There are several major
>> +differences between the two. In @kbd{target extended-remote} mode, GDB
> ^^^
> @value{GDBN}
>
>> +stays connected to @code{gdbserver} after the debugged program exits or you
>> +detach from it, and @code{gdbserver} provides support for the @code{run}
>> +and @code{attach} commands.
>
> Saying "several major differences" and then neither describing them
> nor providing a reference (not even just "described below") will leave
> the reader confused, I think. How about a short summary of the
> differences, e.g. as an itemized list, here?
>
> Also, does the sentence that follow (the last one in the above
> excerpt) need to be here? It reads strange, especially since it
> doesn't seem like it belongs to the aforementioned differences. Maybe
> you could reword it so it did contrast the two modes.
>
> Alternatively, perhaps the following subsections are better rearranged
> as extended descriptions of each of the differences, e.g. using @table.
> Right now, they read somewhat confusingly, because the description
> jumps between the two modes without providing any intermediate summary
> for the reader, and thus it is easy to become confused as to what mode
> and what difference you are describing. Some better organization of
> the same material could help the reader organize their thoughts and
> come out with a better understanding of the differences.
I went with the latter suggestion. I hope my interpretation of this
doesn't violate any doc conventions. In the previous version I had
tried to leave some paragraphs unmodified, just reorganizing where
they were. I've been more liberal in my changes in this version.
>
> Last, but not least: please consider adding @cindex entries to each of
> the subsections, with text that describes the main subject of each
> subsection. In many cases, just the down-cased name of the section is
> a good starting point. This will help the readers find the subsection
> quickly using the Info index-searching commands, which is important
> for using the manual as a reference.
I added a number of these.
>
>> +@item
>> +Finally, connect to your target. For TCP connections, you must start up
>> +@code{gdbserver} prior to using the @kbd{target remote} or
>> +@kbd{target extended-remote} command. Otherwise you may get an error
>> +whose text depends on the host system, but which usually looks something
>> +like @samp{Connection refused}. Don't use the @code{load} command in
>> +@value{GDBN} when using @code{gdbserver}, since the program is already on
>> +the target.
>
> There's some inconsistency in your usage of @code and @kbd markup for
> commands. In general, the correct markup is @kbd when the context is
> about commands typed by the user, and @code otherwise. (The GDB
> manual almost never uses @kbd, for historical reasons, btw.) You have
> changed some of the @code to @kbd regardless of context, or so it
> seems. But in the above passage, you use @code as well, so I'm unsure
> what is your rule for selecting one or the other.
I misunderstood the convention here. Thanks for clarifying. I think I
have more-or-less restored things. Basically, as I understand it, the rule
is: use @kbd where the sentence is saying "type @kbd{foo}" or "use
@kbd{foo}", but use @code if it is just referring to it, like "in the
case of the @code{foo} command".
>
>> @item target remote @var{serial-device}
>> -@cindex serial line, @code{target remote}
>> +@item target extended-remote @var{serial-device}
> ^^^^^
> Should be @itemx.
I fixed all of these.
>> -@subsection Running @code{gdbserver}
>> +@subsection Running gdbserver
>
> Not sure why you removed the markup from "gdbserver" here.
My ignorance about how to implement cross-references. I've figured out
the right thing to do, and restored the markup.
Let me know what you think about this version.
thanks
--Don
-----------------------
This patch implements documentation updates for target remote mode
fork and exec events. A summary of the rationale for the changes
made here:
* Types of Remote Connections -- explain that the two protocols exist,
and describe the differences between the two.
* Host and Target Files -- collect paragraphs dealing with how to locate
symbol files from original sections "Connecting to a remote target" and
"Using the gdbserver program | Connecting to gdbserver".
* Remote connection commands -- used to be the bulk of "Connecting to a
remote target". Added "target extended-remote" commands and information.
Thanks,
--Don
gdb/
2015-11-11 Don Breazeal <donb@sourceware.org>
* NEWS: Announce fork and exec event support for target remote.
gdb/doc/
2015-11-11 Don Breazeal <donb@sourceware.org>
* gdb.texinfo (Forks): Correct Linux kernel version where
fork and exec events are supported, add notes about support
of these events in target remote mode.
(Connecting): Reorganize and clarify distinctions between
target remote, extended-remote, and multiprocess.
Reorganize related text from separate sections into new
sections.
(Server): Note effects of target extended-remote mode.
Delete section on Multi-Process Mode for gdbserver.
Move some text to "Connecting" node.
---
gdb/NEWS | 8 ++
gdb/doc/gdb.texinfo | 272 +++++++++++++++++++++++++++++++++++++---------------
2 files changed, 202 insertions(+), 78 deletions(-)
diff --git a/gdb/NEWS b/gdb/NEWS
index b2b1e99..166a6ca 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -87,6 +87,14 @@ set remote exec-event-feature-packet
show remote exec-event-feature-packet
Set/show the use of the remote exec event feature.
+* Target remote mode fork and exec events
+
+ ** GDB now has support for fork and exec events on target remote mode
+ Linux targets. For such targets with Linux kernels 2.5.46 and later,
+ this enables follow-fork-mode, detach-on-fork and fork and exec
+ catchpoints. Note that follow-exec-mode is not supported, because
+ target remote mode does not support the 'run' command.
+
*** Changes in GDB 7.10
* Support for process record-replay and reverse debugging on aarch64*-linux*
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 3c1f785..4adbfed 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -3133,10 +3133,11 @@ the child process just like any other process which you attached to.
On some systems, @value{GDBN} provides support for debugging programs that
create additional processes using the @code{fork} or @code{vfork} functions.
Currently, the only platforms with this feature are HP-UX (11.x and later
-only?) and @sc{gnu}/Linux (kernel version 2.5.60 and later).
+only?) and @sc{gnu}/Linux (kernel version 2.5.46 and later).
-The fork debugging commands are supported in both native mode and when
-connected to @code{gdbserver} using @kbd{target extended-remote}.
+The fork debugging commands are supported in native mode and when
+connected to @code{gdbserver} in either @code{target remote} mode or
+@code{target extended-remote} mode.
By default, when a program forks, @value{GDBN} will continue to debug
the parent process and the child process will run unimpeded.
@@ -3282,6 +3283,11 @@ Program exited normally.
@end table
@end table
+@code{follow-exec-mode} is supported in native mode and
+@code{target extended-remote} mode. It has no real effect in
+@code{target remote} mode since the run command is not supported in that
+mode.
+
You can use the @code{catch} command to make @value{GDBN} stop whenever
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting Catchpoints}.
@@ -19220,28 +19226,150 @@ configuration of @value{GDBN}; use @code{help target} to list them.
@node Connecting
@section Connecting to a Remote Target
+@cindex remote debugging, connecting
+@cindex @code{gdbserver}, connecting
+@cindex remote debugging, types of connections
+@cindex @code{gdbserver}, types of connections
+@cindex @code{gdbserver}, @code{target remote} mode
+@cindex @code{gdbserver}, @code{target extended-remote} mode
+
+This section describes how to connect to a remote target, including the
+types of connections and their differences, how to set up executable and
+symbol files on the host and target, and the commands used for
+connecting to and disconnecting from the remote target.
+
+@subsection Types of Remote Connections
+
+@value{GDBN} supports two types of remote connections, @code{target remote}
+mode and @code{target extended-remote} mode. Note that many remote targets
+support only @code{target remote} mode. There are several major
+differences between the two types of connections, enumerated here:
+
+@table @asis
+
+@cindex remote debugging, detach and program exit
+@item Result of detach or program exit
+
+@strong{target remote mode:} When the debugged program exits or you
+detach from it, @value{GDBN} disconnects from the target. When using
+@code{gdbserver}, @code{gdbserver} will exit.
+
+@strong{target extended-remote mode:} When the debugged program exits or
+you detach from it, @value{GDBN} remains connected to the target, even
+though no program is running. You can rerun the program, attach to a
+running program, or use @code{monitor} commands specific to the target.
+
+When using @code{gdbserver} in this case, it does not exit unless it was
+invoked using the @option{--once} option. If the @option{--once} option
+was not used, you can ask @code{gdbserver} to exit using the
+@code{monitor exit} command (@pxref{Monitor Commands for gdbserver}).
+
+@item Specifying the program to debug
+
+For both connection types you use the @code{file} command to specify the
+program on the host system. If you are using @code{gdbserver} there are
+some differences in how to specify the location of the program on the
+target.
+
+@strong{target remote mode:} You must either specify the program to debug
+on the @code{gdbserver} command line or use the @option{--attach} option
+(@pxref{Attaching to a program,,Attaching to a Running Program}).
+
+@cindex @option{--multi}, @code{gdbserver} option
+@strong{target extended-remote mode:} You may specify the program to debug
+on the @code{gdbserver} command line, or you can load the program or attach
+to it using @value{GDBN} commands after connecting to @code{gdbserver}.
+
+@anchor{Types of Remote Connnections: --multi option}
+You can start @code{gdbserver} without supplying an initial command to run
+or process ID to attach. To do this, use the @option{--multi} command line
+option. Then you can connect using @code{target extended-remote} and start
+the program you want to debug (see below for details on using the
+@code{run} command in this scenario). Note that the conditions under which
+@code{gdbserver} terminates depend on how @value{GDBN} connects to it
+(@code{target remote} or @code{target extended-remote}). The
+@option{--multi} option to @code{gdbserver} has no influence on that.
-@value{GDBN} needs an unstripped copy of your program to access symbol
-and debugging information. Some remote targets (@pxref{qXfer
-executable filename read}, and @pxref{Host I/O Packets}) allow
-@value{GDBN} to access program files over the same connection used to
-communicate with @value{GDBN}. With such a target, if the remote
-program is unstripped, the only command you need is @code{target
-remote}. Otherwise, start up @value{GDBN} using the name of the local
+@item The @code{run} command
+@strong{target remote mode:} The @code{run} command is not supported.
+Once a connection has been established, you can use all the usual
+@value{GDBN} commands to examine and change data. The remote program
+is already running, so you can use commands like @kbd{step} and
+@kbd{continue}.
+
+@strong{target extended-remote mode:} The @code{run} command is supported.
+The @code{run} command uses the value set by @code{set remote exec-file}
+(@pxref{set remote exec-file}) to select the program to run. Command line
+arguments are supported, except for wildcard expansion and I/O
+redirection (@pxref{Arguments}).
+
+If you specify the program to debug on the command line, then the
+@code{run} command is not required to start execution, and you can
+resume using commands like @kbd{step} and @kbd{continue} as with
+@code{target remote} mode.
+
+@anchor{Types of Remote Connections: Attaching}
+@item Attaching
+@strong{target remote mode:} The @value{GDBN} command @code{attach} is
+not supported. To attach to a running program using @code{gdbserver}, you
+must use the @option{--attach} option (@pxref{Running gdbserver}).
+
+@strong{target extended-remote mode:} To attach to a running program,
+you may use the @code{attach} command after the connection has been
+established. If you are using @code{gdbserver}, you may also invoke
+@code{gdbserver} using the @option{--attach} option
+(@pxref{Running gdbserver}).
+
+@end table
+
+@anchor{Host and target files}
+@subsection Host and Target Files
+@cindex remote debugging, symbol files
+@cindex symbol files, remote debugging
+
+@value{GDBN}, running on the host, needs access to symbol and debugging
+information for your program running on the target. This requires
+access to an unstripped copy of your program, and possibly any associated
+symbol files. Note that this section applies equally to both @code{target
+remote} mode and @code{target extended-remote} mode.
+
+Some remote targets (@pxref{qXfer executable filename read}, and
+@pxref{Host I/O Packets}) allow @value{GDBN} to access program files over
+the same connection used to communicate with @value{GDBN}. With such a
+target, if the remote program is unstripped, the only command you need is
+@code{target remote} (or @code{target extended-remote}).
+
+If the remote program is stripped, or the target does not support remote
+program file access, start up @value{GDBN} using the name of the local
unstripped copy of your program as the first argument, or use the
-@code{file} command.
+@code{file} command. Use @code{set sysroot} to specify the location (on
+the host) of target libraries (unless your @value{GDBN} was compiled with
+the correct sysroot using @code{--with-sysroot}). Alternatively, you
+may use @code{set solib-search-path} to specify how @value{GDBN} locates
+target libraries.
+
+The symbol file and target libraries must exactly match the executable
+and libraries on the target, with one exception: the files on the host
+system should not be stripped, even if the files on the target system
+are. Mismatched or missing files will lead to confusing results
+during debugging. On @sc{gnu}/Linux targets, mismatched or missing
+files may also prevent @code{gdbserver} from debugging multi-threaded
+programs.
-@cindex @code{target remote}
+@subsection Remote Connection Commands
+@cindex remote connection commands
@value{GDBN} can communicate with the target over a serial line, or
over an @acronym{IP} network using @acronym{TCP} or @acronym{UDP}. In
each case, @value{GDBN} uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
-@code{target remote} command establishes a connection to the target.
-Its arguments indicate which medium to use:
+@code{target remote} and @code{target extended-remote} commands
+establish a connection to the target. Both commands accept the same
+arguments, which indicate the medium to use:
@table @code
@item target remote @var{serial-device}
+@itemx target extended-remote @var{serial-device}
@cindex serial line, @code{target remote}
Use @var{serial-device} to communicate with the target. For example,
to use a serial line connected to the device named @file{/dev/ttyb}:
@@ -19253,10 +19381,12 @@ target remote /dev/ttyb
If you're using a serial line, you may want to give @value{GDBN} the
@samp{--baud} option, or use the @code{set serial baud} command
(@pxref{Remote Configuration, set serial baud}) before the
-@code{target} command.
+@kbd{target} command.
@item target remote @code{@var{host}:@var{port}}
@itemx target remote @code{tcp:@var{host}:@var{port}}
+@itemx target extended-remote @code{@var{host}:@var{port}}
+@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
@cindex @acronym{TCP} port, @code{target remote}
Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
The @var{host} may be either a host name or a numeric @acronym{IP}
@@ -19285,6 +19415,7 @@ target remote :1234
Note that the colon is still required here.
@item target remote @code{udp:@var{host}:@var{port}}
+@itemx target extended-remote @code{udp:@var{host}:@var{port}}
@cindex @acronym{UDP} port, @code{target remote}
Debug using @acronym{UDP} packets to @var{port} on @var{host}. For example, to
connect to @acronym{UDP} port 2828 on a terminal server named @code{manyfarms}:
@@ -19299,6 +19430,7 @@ can silently drop packets on busy or unreliable networks, which will
cause havoc with your debugging session.
@item target remote | @var{command}
+@itemx target extended-remote | @var{command}
@cindex pipe, @code{target remote} to
Run @var{command} in the background and communicate with it using a
pipe. The @var{command} is a shell command, to be parsed and expanded
@@ -19314,11 +19446,6 @@ program has already exited, this will have no effect.)
@end table
-Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use @kbd{step} and @kbd{continue}, and you do not
-need to use @kbd{run}.
-
@cindex interrupting remote programs
@cindex remote programs, interrupting
Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -19332,10 +19459,13 @@ Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n)
@end smallexample
-If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
-remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
-goes back to waiting.
+In @code{target remote} mode, if you type @kbd{y}, @value{GDBN} abandons
+the remote debugging session. (If you decide you want to try again later,
+you can use @kbd{target remote} again to connect once more.) If you type
+@kbd{n}, @value{GDBN} goes back to waiting.
+
+In @code{target extended-remote} mode, typing @kbd{n} will leave
+@value{GDBN} connected to the target.
@table @code
@kindex detach (remote)
@@ -19344,11 +19474,13 @@ When you have finished debugging the remote program, you can use the
@code{detach} command to release it from @value{GDBN} control.
Detaching from the target normally resumes its execution, but the results
will depend on your particular remote stub. After the @code{detach}
-command, @value{GDBN} is free to connect to another target.
+command in @code{target remote} mode, @value{GDBN} is free to connect to
+another target. In @code{target extended-remote} mode, @value{GDBN} is
+still connected to the target.
@kindex disconnect
@item disconnect
-The @code{disconnect} command behaves like @code{detach}, except that
+The @code{disconnect} command closes the connection to the target, and
the target is generally not resumed. It will wait for @value{GDBN}
(this instance or another one) to connect and continue debugging. After
the @code{disconnect} command, @value{GDBN} is again free to connect to
@@ -19405,7 +19537,8 @@ Delete @var{targetfile} from the target system.
@cindex remote connection without stubs
@code{gdbserver} is a control program for Unix-like systems, which
allows you to connect your program with a remote @value{GDBN} via
-@code{target remote}---but without linking in the usual debugging stub.
+@code{target remote} or @code{target extended-remote}---but without
+linking in the usual debugging stub.
@code{gdbserver} is not a complete replacement for the debugging stubs,
because it requires essentially the same operating-system facilities
@@ -19433,6 +19566,7 @@ target system with the same privileges as the user running
@code{gdbserver}.
@end quotation
+@anchor{Running gdbserver}
@subsection Running @code{gdbserver}
@cindex arguments, to @code{gdbserver}
@cindex @code{gdbserver}, command-line arguments
@@ -19500,6 +19634,7 @@ Programs started with stdio-connected gdbserver have @file{/dev/null} for
display through a pipe connected to gdbserver.
Both @code{stdout} and @code{stderr} use the same pipe.
+@anchor{Attaching to a program}
@subsubsection Attaching to a Running Program
@cindex attach to a program, @code{gdbserver}
@cindex @option{--attach}, @code{gdbserver} option
@@ -19511,8 +19646,12 @@ This is accomplished via the @code{--attach} argument. The syntax is:
target> gdbserver --attach @var{comm} @var{pid}
@end smallexample
-@var{pid} is the process ID of a currently running process. It isn't necessary
-to point @code{gdbserver} at a binary for the running process.
+@var{pid} is the process ID of a currently running process. It isn't
+necessary to point @code{gdbserver} at a binary for the running process.
+
+In @code{target extended-remote} mode, you can also attach using the
+@value{GDBN} attach command
+(@pxref{Types of Remote Connections: Attaching}).
@pindex pidof
You can debug processes by name instead of process ID if your target has the
@@ -19526,41 +19665,10 @@ In case more than one copy of @var{program} is running, or @var{program}
has multiple threads, most versions of @code{pidof} support the
@code{-s} option to only return the first process ID.
-@subsubsection Multi-Process Mode for @code{gdbserver}
-@cindex @code{gdbserver}, multiple processes
-@cindex multiple processes with @code{gdbserver}
-
-When you connect to @code{gdbserver} using @code{target remote},
-@code{gdbserver} debugs the specified program only once. When the
-program exits, or you detach from it, @value{GDBN} closes the connection
-and @code{gdbserver} exits.
-
-If you connect using @kbd{target extended-remote}, @code{gdbserver}
-enters multi-process mode. When the debugged program exits, or you
-detach from it, @value{GDBN} stays connected to @code{gdbserver} even
-though no program is running. The @code{run} and @code{attach}
-commands instruct @code{gdbserver} to run or attach to a new program.
-The @code{run} command uses @code{set remote exec-file} (@pxref{set
-remote exec-file}) to select the program to run. Command line
-arguments are supported, except for wildcard expansion and I/O
-redirection (@pxref{Arguments}).
-
-@cindex @option{--multi}, @code{gdbserver} option
-To start @code{gdbserver} without supplying an initial command to run
-or process ID to attach, use the @option{--multi} command line option.
-Then you can connect using @kbd{target extended-remote} and start
-the program you want to debug.
-
-In multi-process mode @code{gdbserver} does not automatically exit unless you
-use the option @option{--once}. You can terminate it by using
-@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note that the
-conditions under which @code{gdbserver} terminates depend on how @value{GDBN}
-connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
-@option{--multi} option to @code{gdbserver} has no influence on that.
-
@subsubsection TCP port allocation lifecycle of @code{gdbserver}
-This section applies only when @code{gdbserver} is run to listen on a TCP port.
+This section applies only when @code{gdbserver} is run to listen on a TCP
+port.
@code{gdbserver} normally terminates after all of its debugged processes have
terminated in @kbd{target remote} mode. On the other hand, for @kbd{target
@@ -19591,6 +19699,12 @@ instance closes its port after the first connection.
@anchor{Other Command-Line Arguments for gdbserver}
@subsubsection Other Command-Line Arguments for @code{gdbserver}
+You can use the @option{--multi} option to start @code{gdbserver} without
+specifying a program to debug or a process to attach to. Then you can
+attach in @code{target extended-remote} mode and run or attach to a
+program. For more information,
+@pxref{Types of Remote Connnections: --multi option}.
+
@cindex @option{--debug}, @code{gdbserver} option
The @option{--debug} option tells @code{gdbserver} to display extra
status information about the debugging process.
@@ -19642,32 +19756,34 @@ $ gdbserver --wrapper env LD_PRELOAD=libtest.so -- :2222 ./testprog
@subsection Connecting to @code{gdbserver}
-Run @value{GDBN} on the host system.
+The basic procedure for connecting to the remote target is:
+@itemize
-First make sure you have the necessary symbol files. Load symbols for
-your application using the @code{file} command before you connect. Use
-@code{set sysroot} to locate target libraries (unless your @value{GDBN}
-was compiled with the correct sysroot using @code{--with-sysroot}).
+@item
+Run @value{GDBN} on the host system.
-The symbol file and target libraries must exactly match the executable
-and libraries on the target, with one exception: the files on the host
-system should not be stripped, even if the files on the target system
-are. Mismatched or missing files will lead to confusing results
-during debugging. On @sc{gnu}/Linux targets, mismatched or missing
-files may also prevent @code{gdbserver} from debugging multi-threaded
-programs.
+@item
+Make sure you have the necessary symbol files
+(@pxref{Host and target files}).
+Load symbols for your application using the @code{file} command before you
+connect. Use @code{set sysroot} to locate target libraries (unless your
+@value{GDBN} was compiled with the correct sysroot using
+@code{--with-sysroot}).
+@item
Connect to your target (@pxref{Connecting,,Connecting to a Remote Target}).
For TCP connections, you must start up @code{gdbserver} prior to using
-the @code{target remote} command. Otherwise you may get an error whose
+the @code{target} command. Otherwise you may get an error whose
text depends on the host system, but which usually looks something like
@samp{Connection refused}. Don't use the @code{load}
-command in @value{GDBN} when using @code{gdbserver}, since the program is
-already on the target.
+command in @value{GDBN} when using @code{target remote} mode, since the
+program is already on the target.
+@end itemize
+
+@anchor{Monitor Commands for gdbserver}
@subsection Monitor Commands for @code{gdbserver}
@cindex monitor commands, for @code{gdbserver}
-@anchor{Monitor Commands for gdbserver}
During a @value{GDBN} session using @code{gdbserver}, you can use the
@code{monitor} command to send special requests to @code{gdbserver}.
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-12 1:00 ` Don Breazeal
@ 2015-11-12 16:48 ` Eli Zaretskii
2015-11-13 1:13 ` Don Breazeal
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-11-12 16:48 UTC (permalink / raw)
To: Don Breazeal; +Cc: gdb-patches
> From: Don Breazeal <donb@codesourcery.com>
> Date: Wed, 11 Nov 2015 17:00:00 -0800
>
> >> +@item
> >> +Finally, connect to your target. For TCP connections, you must start up
> >> +@code{gdbserver} prior to using the @kbd{target remote} or
> >> +@kbd{target extended-remote} command. Otherwise you may get an error
> >> +whose text depends on the host system, but which usually looks something
> >> +like @samp{Connection refused}. Don't use the @code{load} command in
> >> +@value{GDBN} when using @code{gdbserver}, since the program is already on
> >> +the target.
> >
> > There's some inconsistency in your usage of @code and @kbd markup for
> > commands. In general, the correct markup is @kbd when the context is
> > about commands typed by the user, and @code otherwise. (The GDB
> > manual almost never uses @kbd, for historical reasons, btw.) You have
> > changed some of the @code to @kbd regardless of context, or so it
> > seems. But in the above passage, you use @code as well, so I'm unsure
> > what is your rule for selecting one or the other.
>
> I misunderstood the convention here. Thanks for clarifying. I think I
> have more-or-less restored things. Basically, as I understand it, the rule
> is: use @kbd where the sentence is saying "type @kbd{foo}" or "use
> @kbd{foo}", but use @code if it is just referring to it, like "in the
> case of the @code{foo} command".
Yes, that's it.
> +@table @asis
> +
> +@cindex remote debugging, detach and program exit
> +@item Result of detach or program exit
> +
> +@strong{target remote mode:} When the debugged program exits or you
> +detach from it, @value{GDBN} disconnects from the target. When using
> +@code{gdbserver}, @code{gdbserver} will exit.
> +
> +@strong{target extended-remote mode:} When the debugged program exits or
This is OK, but the fact that "target extended-remote mode:" part that
begins a sentence doesn't start with a capital letter looks wrong.
How about starting with @strong{With target extended-remote mode:}
instead?
> +@item The @code{run} command
> +@strong{target remote mode:} The @code{run} command is not supported.
Please be consistent regarding whether or not you leave an empty line
after the @item line. (My suggestion is not to leave such a line in a
@table.)
> If you're using a serial line, you may want to give @value{GDBN} the
> @samp{--baud} option, or use the @code{set serial baud} command
> (@pxref{Remote Configuration, set serial baud}) before the
> -@code{target} command.
> +@kbd{target} command.
Here you show 2 commands in the same sentence, one with @code, the
other with @kbd. I think both should use @code.
> +In @code{target extended-remote} mode, you can also attach using the
> +@value{GDBN} attach command
> +(@pxref{Types of Remote Connections: Attaching}).
I don't understand this @pxref -- there's no such node or anchor in
the text. Does this work for you? (Also, using a colon in
cross-reference or node names is a bad idea, as that confuses Info
readers.)
The patch is approved, assuming the above minor issues are fixed.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-12 16:48 ` Eli Zaretskii
@ 2015-11-13 1:13 ` Don Breazeal
2015-11-13 8:16 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-11-13 1:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 11/12/2015 8:48 AM, Eli Zaretskii wrote:
>> From: Don Breazeal <donb@codesourcery.com>
>> Date: Wed, 11 Nov 2015 17:00:00 -0800
>>
>
>> +@table @asis
>> +
>> +@cindex remote debugging, detach and program exit
>> +@item Result of detach or program exit
>> +
>> +@strong{target remote mode:} When the debugged program exits or you
>> +detach from it, @value{GDBN} disconnects from the target. When using
>> +@code{gdbserver}, @code{gdbserver} will exit.
>> +
>> +@strong{target extended-remote mode:} When the debugged program exits or
>
> This is OK, but the fact that "target extended-remote mode:" part that
> begins a sentence doesn't start with a capital letter looks wrong.
> How about starting with @strong{With target extended-remote mode:}
> instead?
>> +@item The @code{run} command
>> +@strong{target remote mode:} The @code{run} command is not supported.
>
> Please be consistent regarding whether or not you leave an empty line
> after the @item line. (My suggestion is not to leave such a line in a
> @table.)
Items above are now done in my sandbox.
>
>> If you're using a serial line, you may want to give @value{GDBN} the
>> @samp{--baud} option, or use the @code{set serial baud} command
>> (@pxref{Remote Configuration, set serial baud}) before the
>> -@code{target} command.
>> +@kbd{target} command.
>
> Here you show 2 commands in the same sentence, one with @code, the
> other with @kbd. I think both should use @code.
>
>> +In @code{target extended-remote} mode, you can also attach using the
>> +@value{GDBN} attach command
>> +(@pxref{Types of Remote Connections: Attaching}).
>
> I don't understand this @pxref -- there's no such node or anchor in
> the text. Does this work for you? (Also, using a colon in
> cross-reference or node names is a bad idea, as that confuses Info
> readers.)
These last two I had fixed in my sandbox but apparently the fixes didn't
make it into the patch I posted, sorry about that. :-S
Regarding the @pxrefs that had colons in them, I have a question. I was
making a cross-reference into the middle of a section, so
there is no section heading to use as the name of the reference. I was
trying to refer to "The part about Attaching that is in the section
'Types of Remote Connections'". How about:
@anchor{Attaching in Types of Remote Connections}
>
> The patch is approved, assuming the above minor issues are fixed.
>
> Thanks.
>
Thanks again for the review and the suggestions.
--Don
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/3] Target remote mode fork and exec docs
2015-11-13 1:13 ` Don Breazeal
@ 2015-11-13 8:16 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-11-13 8:16 UTC (permalink / raw)
To: Don Breazeal; +Cc: gdb-patches
> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> From: Don Breazeal <donb@codesourcery.com>
> Date: Thu, 12 Nov 2015 17:12:55 -0800
>
> >> +In @code{target extended-remote} mode, you can also attach using the
> >> +@value{GDBN} attach command
> >> +(@pxref{Types of Remote Connections: Attaching}).
> >
> > I don't understand this @pxref -- there's no such node or anchor in
> > the text. Does this work for you? (Also, using a colon in
> > cross-reference or node names is a bad idea, as that confuses Info
> > readers.)
>
> These last two I had fixed in my sandbox but apparently the fixes didn't
> make it into the patch I posted, sorry about that. :-S
>
> Regarding the @pxrefs that had colons in them, I have a question. I was
> making a cross-reference into the middle of a section, so
> there is no section heading to use as the name of the reference. I was
> trying to refer to "The part about Attaching that is in the section
> 'Types of Remote Connections'". How about:
>
> @anchor{Attaching in Types of Remote Connections}
That's one possibility, yes. Another is to use @pxref with 2
arguments (see the Texinfo manual for the details), with the 2nd
argument being some phrase that begins the part of the text to which
you want to jump. Unfortunately, the second alternative is only
supported by some Info readers, not all of them.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 1/3] Target remote mode fork and exec events
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
@ 2015-11-20 13:04 ` Pedro Alves
2015-11-20 16:50 ` Don Breazeal
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
0 siblings, 2 replies; 24+ messages in thread
From: Pedro Alves @ 2015-11-20 13:04 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
Hi Don,
Thanks for doing this. Starting to look at the series.
On 11/06/2015 11:56 PM, Don Breazeal wrote:
> This patch implements support for fork and exec events with target remote
> mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
> this enables follow-fork-mode, detach-on-fork and fork and exec
> catchpoints.
> Note that follow-exec-mode is not supported, because target
> remote mode does not support the 'run' command.
Not sure I don't understand this part/comment.
>
> The changes required to implement this included:
>
> * Don't exit from gdbserver if there are still active inferiors.
>
> * Allow changing the active process in remote mode.
>
> * Enable fork and exec events in remote mode.
>
> * Print "Ending remote debugging" when detaching only if in remote
> mode and there is only one inferior left.
>
> (As I write this up I'm concluding that this is incorrect. We
> don't care how many active inferiors there are, yes?
Not sure I understand the question. But I'd say what matters is
whether we're disconnecting/closing the connection.
> Perhaps we
> need a test that detaches when there are multiple inferiors. I've
> added that to my list.)
>
> * Combine remote_kill and extended_remote_kill into a single function
> that can handle the multiple inferior case for target remote. Also,
> the same thing for remote_mourn and extended_remote_mourn.
>
> * Enable process-style ptids in target remote.
>
> * Remove restriction on multiprocess mode in target remote.
>
> Thanks
> --Don
>
> gdb/gdbserver/
> 2015-11-06 Don Breazeal <donb@sourceware.org>
>
> * server.c (process_serial_event): Don't exit from gdbserver
> in remote mode if there are still active inferiors.
>
> gdb/
> 2015-11-06 Don Breazeal <donb@sourceware.org>
>
> * remote.c (set_general_process): Remove restriction on target
> remote mode.
> (remote_query_supported): Likewise.
> (remote_detach_1): Change restriction to target remote mode to
> restriction to last inferior left.
> (remote_disconnect): Unpush the target directly instead of
> calling remote_mourn.
> (remote_kill, extended_remote_kill): Combine functions into one,
> remote_kill, and enable extended functionality for target remote.
> (remote_mourn, extended_remote_mourn): Combine functions into
> one, remote_mourn, and enable extended functionality for target
> remote.
> (remote_pid_to_str): Enable "process" style ptid string for
> target remote.
> (remote_supports_multi_process): Remove restriction on target
> remote mode.
>
> ---
> gdb/gdbserver/server.c | 6 +-
> gdb/remote.c | 166 ++++++++++++++++++++++++-------------------------
> 2 files changed, 84 insertions(+), 88 deletions(-)
>
> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
> index fd2804b..0f57237 100644
> --- a/gdb/gdbserver/server.c
> +++ b/gdb/gdbserver/server.c
> @@ -3865,9 +3865,11 @@ process_serial_event (void)
> discard_queued_stop_replies (pid_to_ptid (pid));
> write_ok (own_buf);
>
> - if (extended_protocol)
> + if (extended_protocol || get_first_inferior (&all_threads) != NULL)
> {
> - /* Treat this like a normal program exit. */
> + /* There is still at least one inferior remaining, so
> + don't terminate gdbserver and treat this like a
> + normal program exit. */
> last_status.kind = TARGET_WAITKIND_EXITED;
> last_status.value.integer = 0;
> last_ptid = pid_to_ptid (pid);
> diff --git a/gdb/remote.c b/gdb/remote.c
> index fed397a..60da26c 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -123,8 +123,6 @@ static void remote_mourn (struct target_ops *ops);
>
> static void extended_remote_restart (void);
>
> -static void extended_remote_mourn (struct target_ops *);
> -
> static void remote_send (char **buf, long *sizeof_buf_p);
>
> static int readchar (int timeout);
> @@ -2084,7 +2082,7 @@ set_general_process (void)
> struct remote_state *rs = get_remote_state ();
>
> /* If the remote can't handle multiple processes, don't bother. */
> - if (!rs->extended || !remote_multi_process_p (rs))
> + if (!remote_multi_process_p (rs))
> return;
>
> /* We only need to change the remote current thread if it's pointing
> @@ -4472,18 +4470,15 @@ remote_query_supported (void)
>
> q = remote_query_supported_append (q, "qRelocInsn+");
>
> - if (rs->extended)
> - {
> - if (packet_set_cmd_state (PACKET_fork_event_feature)
> - != AUTO_BOOLEAN_FALSE)
> - q = remote_query_supported_append (q, "fork-events+");
> - if (packet_set_cmd_state (PACKET_vfork_event_feature)
> - != AUTO_BOOLEAN_FALSE)
> - q = remote_query_supported_append (q, "vfork-events+");
> - if (packet_set_cmd_state (PACKET_exec_event_feature)
> - != AUTO_BOOLEAN_FALSE)
> - q = remote_query_supported_append (q, "exec-events+");
> - }
> + if (packet_set_cmd_state (PACKET_fork_event_feature)
> + != AUTO_BOOLEAN_FALSE)
> + q = remote_query_supported_append (q, "fork-events+");
> + if (packet_set_cmd_state (PACKET_vfork_event_feature)
> + != AUTO_BOOLEAN_FALSE)
> + q = remote_query_supported_append (q, "vfork-events+");
> + if (packet_set_cmd_state (PACKET_exec_event_feature)
> + != AUTO_BOOLEAN_FALSE)
> + q = remote_query_supported_append (q, "exec-events+");
>
> if (packet_set_cmd_state (PACKET_vContSupported) != AUTO_BOOLEAN_FALSE)
> q = remote_query_supported_append (q, "vContSupported+");
> @@ -4827,7 +4822,8 @@ remote_detach_1 (const char *args, int from_tty)
> /* Tell the remote target to detach. */
> remote_detach_pid (pid);
>
> - if (from_tty && !rs->extended)
> + /* Exit only if this is the only active inferior. */
> + if (from_tty && !rs->extended && number_of_inferiors () == 1)
> puts_filtered (_("Ending remote debugging.\n"));
>
> /* Check to see if we are detaching a fork parent. Note that if we
> @@ -4923,10 +4919,11 @@ remote_disconnect (struct target_ops *target, const char *args, int from_tty)
> if (args)
> error (_("Argument given to \"disconnect\" when remotely debugging."));
>
> - /* Make sure we unpush even the extended remote targets; mourn
> - won't do it. So call remote_mourn directly instead of
> - target_mourn_inferior. */
> - remote_mourn (target);
> + /* Make sure we unpush even the extended remote targets. Calling
> + target_mourn_inferior won't unpush, and remote_mourn won't
> + unpush if there is more than one inferior left. */
> + unpush_target (target);
> + generic_mourn_inferior ();
Note: this generic_mourn_inferior call here looks wrong, because we may be
debugging more than one inferior. But remote_mourn was already wrong
for the same reason, so, not a problem added by this patch.
>
> if (from_tty)
> puts_filtered ("Ending remote debugging.\n");
> @@ -8562,42 +8559,6 @@ kill_new_fork_children (int pid, struct remote_state *rs)
> }
>
> \f
> -static void
> -remote_kill (struct target_ops *ops)
> -{
Please rename this (making it a helper function) instead of inlining
it in the new remote_kill. E.g., remote_kill_k.
> -
> - /* Catch errors so the user can quit from gdb even when we
> - aren't on speaking terms with the remote system. */
> - TRY
> - {
> - putpkt ("k");
> - }
> - CATCH (ex, RETURN_MASK_ERROR)
> - {
> - if (ex.error == TARGET_CLOSE_ERROR)
> - {
> - /* If we got an (EOF) error that caused the target
> - to go away, then we're done, that's what we wanted.
> - "k" is susceptible to cause a premature EOF, given
> - that the remote server isn't actually required to
> - reply to "k", and it can happen that it doesn't
> - even get to reply ACK to the "k". */
> - return;
> - }
> -
> - /* Otherwise, something went wrong. We didn't actually kill
> - the target. Just propagate the exception, and let the
> - user or higher layers decide what to do. */
> - throw_exception (ex);
> - }
> - END_CATCH
> -
> - /* We've killed the remote end, we get to mourn it. Since this is
> - target remote, single-process, mourning the inferior also
> - unpushes remote_ops. */
> - target_mourn_inferior ();
Maybe do still move this mourn out into new remote_kill.
> -}
> -
> static int
> remote_vkill (int pid, struct remote_state *rs)
> {
> @@ -8624,19 +8585,58 @@ remote_vkill (int pid, struct remote_state *rs)
> }
>
> static void
> -extended_remote_kill (struct target_ops *ops)
> +remote_kill (struct target_ops *ops)
> {
> int res;
> int pid = ptid_get_pid (inferior_ptid);
> struct remote_state *rs = get_remote_state ();
>
> + /* If we are in 'target remote' mode and we are killing the only
> + inferior, then we will tell gdbserver to exit and unpush the
> + target. */
> + if (!rs->extended && number_of_inferiors () <= 1)
It's number of inferiors, or number of _live_ inferiors that matters?
I'd think the latter. Likewise all other new number_of_inferiors
calls should be audited.
> + {
> + /* Catch errors so the user can quit from gdb even when we
> + aren't on speaking terms with the remote system. */
> + TRY
> + {
> + putpkt ("k");
> + }
> + CATCH (ex, RETURN_MASK_ERROR)
> + {
> + if (ex.error == TARGET_CLOSE_ERROR)
> + {
> + /* If we got an (EOF) error that caused the target
> + to go away, then we're done, that's what we wanted.
> + "k" is susceptible to cause a premature EOF, given
> + that the remote server isn't actually required to
> + reply to "k", and it can happen that it doesn't
> + even get to reply ACK to the "k". */
> + return;
> + }
> +
> + /* Otherwise, something went wrong. We didn't actually kill
> + the target. Just propagate the exception, and let the
> + user or higher layers decide what to do. */
> + throw_exception (ex);
> + }
> + END_CATCH
> +
> + /* We've killed the remote end, we get to mourn it. Since this is
> + target remote, single-process, mourning the inferior also
> + unpushes remote_ops. */
Mentioning "single-process," here no longer looks right to me.
> + target_mourn_inferior ();
> +
> + return;
> + }
> +
> /* If we're stopped while forking and we haven't followed yet, kill the
> child task. We need to do this before killing the parent task
> because if this is a vfork then the parent will be sleeping. */
> kill_new_fork_children (pid, rs);
>
> res = remote_vkill (pid, rs);
> - if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
> + if (res == -1 && !(remote_multi_process_p (rs)))
Drop the now-unnecessary parens.
> {
> /* Don't try 'k' on a multi-process aware stub -- it has no way
> to specify the pid. */
I wonder about re-writing this function in top-down approach?
#0 - if vkill is supported:
- kill the new fork children first.
- then kill the current process with remote_vkill.
#1 - then if not multi-process, and there are still
live processes, call the new remote_kill_k helper, to kill
with "k".
#2 - then, if !extended, and there are no live processes
left, disconnect.
Note this also gets rid of the putpkt("k") call, which currently misses
handling the EOF issue already handled by the (new) remote_kill_k.
> @@ -8662,16 +8662,17 @@ extended_remote_kill (struct target_ops *ops)
> static void
> remote_mourn (struct target_ops *target)
> {
> - unpush_target (target);
> + struct remote_state *rs = get_remote_state ();
>
> - /* remote_close takes care of doing most of the clean up. */
> - generic_mourn_inferior ();
> -}
> + /* In 'target remote' mode with one inferior, we shut down gdbserver. */
I'd rather say:
/* In 'target remote' mode with one inferior, we close the connection. */
> + if (!rs->extended && number_of_inferiors () <= 1)
> + {
> + unpush_target (target);
>
> -static void
> -extended_remote_mourn (struct target_ops *target)
> -{
> - struct remote_state *rs = get_remote_state ();
> + /* remote_close takes care of doing most of the clean up. */
> + generic_mourn_inferior ();
> + return;
> + }
>
> /* In case we got here due to an error, but we're going to stay
> connected. */
> @@ -8702,8 +8703,9 @@ extended_remote_mourn (struct target_ops *target)
> current thread. */
> record_currthread (rs, minus_one_ptid);
>
> - /* Unlike "target remote", we do not want to unpush the target; then
> - the next time the user says "run", we won't be connected. */
> + /* Unlike 'target remote' with no more inferiors, we do not want to
> + unpush the target. If we do then the next time the user says
> + "run", we won't be connected. */
>
> /* Call common code to mark the inferior as not running. */
> generic_mourn_inferior ();
> @@ -10224,7 +10226,7 @@ remote_pid_to_str (struct target_ops *ops, ptid_t ptid)
> {
> if (ptid_equal (magic_null_ptid, ptid))
> xsnprintf (buf, sizeof buf, "Thread <main>");
> - else if (rs->extended && remote_multi_process_p (rs))
> + else if (remote_multi_process_p (rs))
> if (ptid_get_lwp (ptid) == 0)
> return normal_pid_to_str (ptid);
> else
> @@ -11398,7 +11400,7 @@ remote_supports_multi_process (struct target_ops *self)
> processes, even though plain remote can use the multi-process
> thread id extensions, so that GDB knows the target process's
> PID. */
Comment above needs updating.
> - return rs->extended && remote_multi_process_p (rs);
> + return remote_multi_process_p (rs);
> }
>
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 1/3] Target remote mode fork and exec events
2015-11-20 13:04 ` Pedro Alves
@ 2015-11-20 16:50 ` Don Breazeal
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
1 sibling, 0 replies; 24+ messages in thread
From: Don Breazeal @ 2015-11-20 16:50 UTC (permalink / raw)
To: Pedro Alves, gdb-patches
On 11/20/2015 5:04 AM, Pedro Alves wrote:
> Hi Don,
>
> Thanks for doing this. Starting to look at the series.
Thanks!
>
> On 11/06/2015 11:56 PM, Don Breazeal wrote:
>> This patch implements support for fork and exec events with target remote
>> mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
>> this enables follow-fork-mode, detach-on-fork and fork and exec
>> catchpoints.
>
>> Note that follow-exec-mode is not supported, because target
>> remote mode does not support the 'run' command.
>
> Not sure I don't understand this part/comment.
I assume that we agree that the 'run' command is not supported in target
remote mode.
Maybe a better way to have stated this would be that follow-exec-mode is
of limited used in target remote mode, since the 'run' command is not
supported. The point being that the main reason a user would want to
set follow-exec-mode would be to get control over which inferior is run
when a 'run' command is executed.
I have to admit that it is incorrect to say that it is unsupported,
since setting follow-exec-mode *will* control whether a new inferior or
the same inferior is used for the execed program. But there isn't much
you can do differently without the 'run' command. Using
follow-exec-mode 'new' there *is* a record of what programs have been
run, which could be useful.
Is that a more accurate description, or am I misunderstanding something?
I'll get to work on the rest of this, hopefully sometime next week.
thanks
--Don
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 2/3] Target remote mode fork and exec events
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
@ 2015-12-07 22:14 ` Don Breazeal
2015-12-08 12:55 ` Pedro Alves
2015-12-07 22:14 ` [PATCH v2 1/3] Target remote mode fork and exec tests Don Breazeal
` (2 subsequent siblings)
3 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-12-07 22:14 UTC (permalink / raw)
To: gdb-patches
Hi Pedro,
This is version two of a patch to implement support for fork and
exec events in target remote mode. The differences from the previous
version are all based on the comments from the previous review, as
follows:
On 11/20/2015 5:04 AM, Pedro Alves wrote:
> Hi Don,
>
> Thanks for doing this. Starting to look at the series.
>
> On 11/06/2015 11:56 PM, Don Breazeal wrote:
>> This patch implements support for fork and exec events with target remote
>> mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
>> this enables follow-fork-mode, detach-on-fork and fork and exec
>> catchpoints.
>
>> Note that follow-exec-mode is not supported, because target
>> remote mode does not support the 'run' command.
>
> Not sure I don't understand this part/comment.
As I noted in my previous reply, this was an overly-pessimistic way of
putting it. I revised the docs etc to say something like this:
"follow-exec-mode is of limited used in target remote mode, since the 'run'
command is not supported." The point being that the main reason a user
would want to set follow-exec-mode would be to get control over which
inferior is run when a 'run' command is executed. It is supported in
that the inferiors are created or not created as specified, and one could
(for example) use follow-exec-mode to keep a record of the programs that
were executed.
>>
>> The changes required to implement this included:
>>
>> * Don't exit from gdbserver if there are still active inferiors.
>>
>> * Allow changing the active process in remote mode.
>>
>> * Enable fork and exec events in remote mode.
>>
>> * Print "Ending remote debugging" when detaching only if in remote
>> mode and there is only one inferior left.
>>
>> (As I write this up I'm concluding that this is incorrect. We
>> don't care how many active inferiors there are, yes?
>
> Not sure I understand the question. But I'd say what matters is
> whether we're disconnecting/closing the connection.
Agreed.
>> Perhaps we
>> need a test that detaches when there are multiple inferiors. I've
>> added that to my list.)
>>
>> * Combine remote_kill and extended_remote_kill into a single function
>> that can handle the multiple inferior case for target remote. Also,
>> the same thing for remote_mourn and extended_remote_mourn.
>>
>> * Enable process-style ptids in target remote.
>>
>> * Remove restriction on multiprocess mode in target remote.
>>
>> Thanks
>> --Don
>>
>> gdb/gdbserver/
>> 2015-11-06 Don Breazeal <donb@sourceware.org>
>>
>> * server.c (process_serial_event): Don't exit from gdbserver
>> in remote mode if there are still active inferiors.
>>
>> gdb/
>> 2015-11-06 Don Breazeal <donb@sourceware.org>
>>
>> * remote.c (set_general_process): Remove restriction on target
>> remote mode.
>> (remote_query_supported): Likewise.
>> (remote_detach_1): Change restriction to target remote mode to
>> restriction to last inferior left.
>> (remote_disconnect): Unpush the target directly instead of
>> calling remote_mourn.
>> (remote_kill, extended_remote_kill): Combine functions into one,
>> remote_kill, and enable extended functionality for target remote.
>> (remote_mourn, extended_remote_mourn): Combine functions into
>> one, remote_mourn, and enable extended functionality for target
>> remote.
>> (remote_pid_to_str): Enable "process" style ptid string for
>> target remote.
>> (remote_supports_multi_process): Remove restriction on target
>> remote mode.
>>
>> ---
>> gdb/gdbserver/server.c | 6 +-
>> gdb/remote.c | 166 ++++++++++++++++++++++++-------------------------
>> 2 files changed, 84 insertions(+), 88 deletions(-)
>>
>> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
>> index fd2804b..0f57237 100644
>> --- a/gdb/gdbserver/server.c
>> +++ b/gdb/gdbserver/server.c
>> @@ -3865,9 +3865,11 @@ process_serial_event (void)
>> discard_queued_stop_replies (pid_to_ptid (pid));
>> write_ok (own_buf);
>>
>> - if (extended_protocol)
>> + if (extended_protocol || get_first_inferior (&all_threads) != NULL)
>> {
>> - /* Treat this like a normal program exit. */
>> + /* There is still at least one inferior remaining, so
>> + don't terminate gdbserver and treat this like a
>> + normal program exit. */
>> last_status.kind = TARGET_WAITKIND_EXITED;
>> last_status.value.integer = 0;
>> last_ptid = pid_to_ptid (pid);
>> diff --git a/gdb/remote.c b/gdb/remote.c
>> index fed397a..60da26c 100644
>> --- a/gdb/remote.c
>> +++ b/gdb/remote.c
>> @@ -123,8 +123,6 @@ static void remote_mourn (struct target_ops *ops);
>>
>> static void extended_remote_restart (void);
>>
>> -static void extended_remote_mourn (struct target_ops *);
>> -
>> static void remote_send (char **buf, long *sizeof_buf_p);
>>
>> static int readchar (int timeout);
>> @@ -2084,7 +2082,7 @@ set_general_process (void)
>> struct remote_state *rs = get_remote_state ();
>>
>> /* If the remote can't handle multiple processes, don't bother. */
>> - if (!rs->extended || !remote_multi_process_p (rs))
>> + if (!remote_multi_process_p (rs))
>> return;
>>
>> /* We only need to change the remote current thread if it's pointing
>> @@ -4472,18 +4470,15 @@ remote_query_supported (void)
>>
>> q = remote_query_supported_append (q, "qRelocInsn+");
>>
>> - if (rs->extended)
>> - {
>> - if (packet_set_cmd_state (PACKET_fork_event_feature)
>> - != AUTO_BOOLEAN_FALSE)
>> - q = remote_query_supported_append (q, "fork-events+");
>> - if (packet_set_cmd_state (PACKET_vfork_event_feature)
>> - != AUTO_BOOLEAN_FALSE)
>> - q = remote_query_supported_append (q, "vfork-events+");
>> - if (packet_set_cmd_state (PACKET_exec_event_feature)
>> - != AUTO_BOOLEAN_FALSE)
>> - q = remote_query_supported_append (q, "exec-events+");
>> - }
>> + if (packet_set_cmd_state (PACKET_fork_event_feature)
>> + != AUTO_BOOLEAN_FALSE)
>> + q = remote_query_supported_append (q, "fork-events+");
>> + if (packet_set_cmd_state (PACKET_vfork_event_feature)
>> + != AUTO_BOOLEAN_FALSE)
>> + q = remote_query_supported_append (q, "vfork-events+");
>> + if (packet_set_cmd_state (PACKET_exec_event_feature)
>> + != AUTO_BOOLEAN_FALSE)
>> + q = remote_query_supported_append (q, "exec-events+");
>>
>> if (packet_set_cmd_state (PACKET_vContSupported) != AUTO_BOOLEAN_FALSE)
>> q = remote_query_supported_append (q, "vContSupported+");
>> @@ -4827,7 +4822,8 @@ remote_detach_1 (const char *args, int from_tty)
>> /* Tell the remote target to detach. */
>> remote_detach_pid (pid);
>>
>> - if (from_tty && !rs->extended)
>> + /* Exit only if this is the only active inferior. */
>> + if (from_tty && !rs->extended && number_of_inferiors () == 1)
>> puts_filtered (_("Ending remote debugging.\n"));
>>
>> /* Check to see if we are detaching a fork parent. Note that if we
>> @@ -4923,10 +4919,11 @@ remote_disconnect (struct target_ops *target, const char *args, int from_tty)
>> if (args)
>> error (_("Argument given to \"disconnect\" when remotely debugging."));
>>
>> - /* Make sure we unpush even the extended remote targets; mourn
>> - won't do it. So call remote_mourn directly instead of
>> - target_mourn_inferior. */
>> - remote_mourn (target);
>> + /* Make sure we unpush even the extended remote targets. Calling
>> + target_mourn_inferior won't unpush, and remote_mourn won't
>> + unpush if there is more than one inferior left. */
>> + unpush_target (target);
>> + generic_mourn_inferior ();
>
> Note: this generic_mourn_inferior call here looks wrong, because we may be
> debugging more than one inferior. But remote_mourn was already wrong
> for the same reason, so, not a problem added by this patch.
OK, I'll leave it in place for now.
>>
>> if (from_tty)
>> puts_filtered ("Ending remote debugging.\n");
>> @@ -8562,42 +8559,6 @@ kill_new_fork_children (int pid, struct remote_state *rs)
>> }
>>
>> \f
>> -static void
>> -remote_kill (struct target_ops *ops)
>> -{
>
> Please rename this (making it a helper function) instead of inlining
> it in the new remote_kill. E.g., remote_kill_k.
Done.
>> -
>> - /* Catch errors so the user can quit from gdb even when we
>> - aren't on speaking terms with the remote system. */
>> - TRY
>> - {
>> - putpkt ("k");
>> - }
>> - CATCH (ex, RETURN_MASK_ERROR)
>> - {
>> - if (ex.error == TARGET_CLOSE_ERROR)
>> - {
>> - /* If we got an (EOF) error that caused the target
>> - to go away, then we're done, that's what we wanted.
>> - "k" is susceptible to cause a premature EOF, given
>> - that the remote server isn't actually required to
>> - reply to "k", and it can happen that it doesn't
>> - even get to reply ACK to the "k". */
>> - return;
>> - }
>> -
>> - /* Otherwise, something went wrong. We didn't actually kill
>> - the target. Just propagate the exception, and let the
>> - user or higher layers decide what to do. */
>> - throw_exception (ex);
>> - }
>> - END_CATCH
>> -
>> - /* We've killed the remote end, we get to mourn it. Since this is
>> - target remote, single-process, mourning the inferior also
>> - unpushes remote_ops. */
>> - target_mourn_inferior ();
>
> Maybe do still move this mourn out into new remote_kill.
Done.
>> -}
>> -
>> static int
>> remote_vkill (int pid, struct remote_state *rs)
>> {
>> @@ -8624,19 +8585,58 @@ remote_vkill (int pid, struct remote_state *rs)
>> }
>>
>> static void
>> -extended_remote_kill (struct target_ops *ops)
>> +remote_kill (struct target_ops *ops)
>> {
>> int res;
>> int pid = ptid_get_pid (inferior_ptid);
>> struct remote_state *rs = get_remote_state ();
>>
>> + /* If we are in 'target remote' mode and we are killing the only
>> + inferior, then we will tell gdbserver to exit and unpush the
>> + target. */
>> + if (!rs->extended && number_of_inferiors () <= 1)
>
> It's number of inferiors, or number of _live_ inferiors that matters?
> I'd think the latter. Likewise all other new number_of_inferiors
> calls should be audited.
Agreed, it is number of _live_ inferiors. I've written a new function
for that called number_of_live_inferiors, since it was a bit problematic
finding an existing mechanism that could determine whether an inferior
that had a non-zero pid but no threads was actually live. That case
shows up in remote_mourn, for example.
>> + {
>> + /* Catch errors so the user can quit from gdb even when we
>> + aren't on speaking terms with the remote system. */
>> + TRY
>> + {
>> + putpkt ("k");
>> + }
>> + CATCH (ex, RETURN_MASK_ERROR)
>> + {
>> + if (ex.error == TARGET_CLOSE_ERROR)
>> + {
>> + /* If we got an (EOF) error that caused the target
>> + to go away, then we're done, that's what we wanted.
>> + "k" is susceptible to cause a premature EOF, given
>> + that the remote server isn't actually required to
>> + reply to "k", and it can happen that it doesn't
>> + even get to reply ACK to the "k". */
>> + return;
>> + }
>> +
>> + /* Otherwise, something went wrong. We didn't actually kill
>> + the target. Just propagate the exception, and let the
>> + user or higher layers decide what to do. */
>> + throw_exception (ex);
>> + }
>> + END_CATCH
>> +
>> + /* We've killed the remote end, we get to mourn it. Since this is
>> + target remote, single-process, mourning the inferior also
>> + unpushes remote_ops. */
>
> Mentioning "single-process," here no longer looks right to me.
I've updated this comment.
>> + target_mourn_inferior ();
>> +
>> + return;
>> + }
>> +
>> /* If we're stopped while forking and we haven't followed yet, kill the
>> child task. We need to do this before killing the parent task
>> because if this is a vfork then the parent will be sleeping. */
>> kill_new_fork_children (pid, rs);
>>
>> res = remote_vkill (pid, rs);
>> - if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
>> + if (res == -1 && !(remote_multi_process_p (rs)))
>
> Drop the now-unnecessary parens.
Done.
>
>> {
>> /* Don't try 'k' on a multi-process aware stub -- it has no way
>> to specify the pid. */
>
>
> I wonder about re-writing this function in top-down approach?
>
> #0 - if vkill is supported:
>
> - kill the new fork children first.
>
> - then kill the current process with remote_vkill.
>
> #1 - then if not multi-process, and there are still
> live processes, call the new remote_kill_k helper, to kill
> with "k".
>
> #2 - then, if !extended, and there are no live processes
> left, disconnect.
>
>
> Note this also gets rid of the putpkt("k") call, which currently misses
> handling the EOF issue already handled by the (new) remote_kill_k.
I did the rewrite of the function as you suggested here. Note that for
step #2 above, the check for "!extended and no live processes" happens
inside remote_mourn.
>
>> @@ -8662,16 +8662,17 @@ extended_remote_kill (struct target_ops *ops)
>> static void
>> remote_mourn (struct target_ops *target)
>> {
>> - unpush_target (target);
>> + struct remote_state *rs = get_remote_state ();
>>
>> - /* remote_close takes care of doing most of the clean up. */
>> - generic_mourn_inferior ();
>> -}
>> + /* In 'target remote' mode with one inferior, we shut down gdbserver. */
>
> I'd rather say:
>
> /* In 'target remote' mode with one inferior, we close the connection. */
Done.
>
>> + if (!rs->extended && number_of_inferiors () <= 1)
>> + {
>> + unpush_target (target);
>>
>> -static void
>> -extended_remote_mourn (struct target_ops *target)
>> -{
>> - struct remote_state *rs = get_remote_state ();
>> + /* remote_close takes care of doing most of the clean up. */
>> + generic_mourn_inferior ();
>> + return;
>> + }
>>
>> /* In case we got here due to an error, but we're going to stay
>> connected. */
>> @@ -8702,8 +8703,9 @@ extended_remote_mourn (struct target_ops *target)
>> current thread. */
>> record_currthread (rs, minus_one_ptid);
>>
>> - /* Unlike "target remote", we do not want to unpush the target; then
>> - the next time the user says "run", we won't be connected. */
>> + /* Unlike 'target remote' with no more inferiors, we do not want to
>> + unpush the target. If we do then the next time the user says
>> + "run", we won't be connected. */
>>
>> /* Call common code to mark the inferior as not running. */
>> generic_mourn_inferior ();
>> @@ -10224,7 +10226,7 @@ remote_pid_to_str (struct target_ops *ops, ptid_t ptid)
>> {
>> if (ptid_equal (magic_null_ptid, ptid))
>> xsnprintf (buf, sizeof buf, "Thread <main>");
>> - else if (rs->extended && remote_multi_process_p (rs))
>> + else if (remote_multi_process_p (rs))
>> if (ptid_get_lwp (ptid) == 0)
>> return normal_pid_to_str (ptid);
>> else
>> @@ -11398,7 +11400,7 @@ remote_supports_multi_process (struct target_ops *self)
>> processes, even though plain remote can use the multi-process
>> thread id extensions, so that GDB knows the target process's
>> PID. */
>
> Comment above needs updating.
I just deleted the comment, since it was describing the differences
between remote and extended-remote, and those differences didn't
exist anymore.
>
>> - return rs->extended && remote_multi_process_p (rs);
>> + return remote_multi_process_p (rs);
>> }
>>
>
> Thanks,
> Pedro Alves
>
Tested on x86_64 native, native-gdbserver, native-extended-gdbserver. No
regressions, other than one issue with gdb.reverse/waitpid-reverse.exp.
My version of GDB seemed to evoke an existing KFAIL, and after that I
would get a new FAIL. I didn't see the KFAIL on "master", and so the
subsequent FAIL wouldn't show up either.
Here is the updated patch description and ChangeLog.
Thanks!
--Don
This patch implements support for fork and exec events with target remote
mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
this enables follow-fork-mode, detach-on-fork and fork and exec
catchpoints. Note that follow-exec-mode is not supported, because target
remote mode does not support the 'run' command.
The changes required to implement this included:
* Don't exit from gdbserver if there are still active inferiors.
* Allow changing the active process in remote mode.
* Enable fork and exec events in remote mode.
* Print "Ending remote debugging" only when disconnecting.
* Combine remote_kill and extended_remote_kill into a single function
that can handle the multiple inferior case for target remote. Also,
the same thing for remote_mourn and extended_remote_mourn.
* Enable process-style ptids in target remote.
* Remove restriction on multiprocess mode in target remote.
Thanks
--Don
gdb/gdbserver/
2015-12-07 Don Breazeal <donb@codesourcery.com>
* server.c (process_serial_event): Don't exit from gdbserver
in remote mode if there are still active inferiors.
gdb/
2015-12-07 Don Breazeal <donb@codesourcery.com>
* inferior.c (number_of_live_inferiors): New function.
(have_live_inferiors): Use number_of_live_inferiors in place
of duplicate code.
* inferior.h (number_of_live_inferiors): Declare new function.
* remote.c (set_general_process): Remove restriction on target
remote mode.
(remote_query_supported): Likewise.
(remote_detach_1): Exit in target remote mode only when there
is just one live inferior left.
(remote_disconnect): Unpush the target directly instead of
calling remote_mourn.
(remote_kill): Rewrite function to handle both target remote
and extended-remote. Call remote_kill_k.
(remote_kill_k): New function.
(extended_remote_kill): Delete function.
(remote_mourn, extended_remote_mourn): Combine functions into
one, remote_mourn, and enable extended functionality for target
remote.
(remote_pid_to_str): Enable "process" style ptid string for
target remote.
(remote_supports_multi_process): Remove restriction on target
remote mode.
---
gdb/gdbserver/server.c | 6 +-
gdb/inferior.c | 31 +++++--
gdb/inferior.h | 3 +
gdb/remote.c | 217 ++++++++++++++++++++++++-------------------------
4 files changed, 136 insertions(+), 121 deletions(-)
diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index 5e053b3..2e0e1d5 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -3959,9 +3959,11 @@ process_serial_event (void)
discard_queued_stop_replies (pid_to_ptid (pid));
write_ok (own_buf);
- if (extended_protocol)
+ if (extended_protocol || get_first_inferior (&all_threads) != NULL)
{
- /* Treat this like a normal program exit. */
+ /* There is still at least one inferior remaining, so
+ don't terminate gdbserver and treat this like a
+ normal program exit. */
last_status.kind = TARGET_WAITKIND_EXITED;
last_status.value.integer = 0;
last_ptid = pid_to_ptid (pid);
diff --git a/gdb/inferior.c b/gdb/inferior.c
index 157e236..a0296c8 100644
--- a/gdb/inferior.c
+++ b/gdb/inferior.c
@@ -459,22 +459,41 @@ have_inferiors (void)
return 0;
}
+/* Return the number of live inferiors. We account for the case
+ where an inferior might have a non-zero pid but no threads, as
+ in the middle of a 'mourn' operation. */
+
int
-have_live_inferiors (void)
+number_of_live_inferiors (void)
{
struct inferior *inf;
+ int num_inf = 0;
for (inf = inferior_list; inf; inf = inf->next)
if (inf->pid != 0)
{
struct thread_info *tp;
-
- tp = any_thread_of_process (inf->pid);
- if (tp && target_has_execution_1 (tp->ptid))
- break;
+
+ ALL_NON_EXITED_THREADS (tp)
+ if (tp && ptid_get_pid (tp->ptid) == inf->pid)
+ if (target_has_execution_1 (tp->ptid))
+ {
+ /* Found a live thread in this inferior, go to the next
+ inferior. */
+ ++num_inf;
+ break;
+ }
}
- return inf != NULL;
+ return num_inf;
+}
+
+/* Return true if there is at least one live inferior. */
+
+int
+have_live_inferiors (void)
+{
+ return number_of_live_inferiors () > 0;
}
/* Prune away any unused inferiors, and then prune away no longer used
diff --git a/gdb/inferior.h b/gdb/inferior.h
index d3cf615..78a5ed3 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -490,6 +490,9 @@ extern struct inferior *iterate_over_inferiors (int (*) (struct inferior *,
/* Returns true if the inferior list is not empty. */
extern int have_inferiors (void);
+/* Returns the number of live inferiors (real live processes). */
+extern int number_of_live_inferiors (void);
+
/* Returns true if there are any live inferiors in the inferior list
(not cores, not executables, real live processes). */
extern int have_live_inferiors (void);
diff --git a/gdb/remote.c b/gdb/remote.c
index 52c5df8..d6bae42 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -123,8 +123,6 @@ static void remote_mourn (struct target_ops *ops);
static void extended_remote_restart (void);
-static void extended_remote_mourn (struct target_ops *);
-
static void remote_send (char **buf, long *sizeof_buf_p);
static int readchar (int timeout);
@@ -2097,7 +2095,7 @@ set_general_process (void)
struct remote_state *rs = get_remote_state ();
/* If the remote can't handle multiple processes, don't bother. */
- if (!rs->extended || !remote_multi_process_p (rs))
+ if (!remote_multi_process_p (rs))
return;
/* We only need to change the remote current thread if it's pointing
@@ -4609,18 +4607,15 @@ remote_query_supported (void)
q = remote_query_supported_append (q, "qRelocInsn+");
- if (rs->extended)
- {
- if (packet_set_cmd_state (PACKET_fork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "fork-events+");
- if (packet_set_cmd_state (PACKET_vfork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "vfork-events+");
- if (packet_set_cmd_state (PACKET_exec_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "exec-events+");
- }
+ if (packet_set_cmd_state (PACKET_fork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "fork-events+");
+ if (packet_set_cmd_state (PACKET_vfork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "vfork-events+");
+ if (packet_set_cmd_state (PACKET_exec_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "exec-events+");
if (packet_set_cmd_state (PACKET_vContSupported) != AUTO_BOOLEAN_FALSE)
q = remote_query_supported_append (q, "vContSupported+");
@@ -4975,7 +4970,8 @@ remote_detach_1 (const char *args, int from_tty)
/* Tell the remote target to detach. */
remote_detach_pid (pid);
- if (from_tty && !rs->extended)
+ /* Exit only if this is the only active inferior. */
+ if (from_tty && !rs->extended && number_of_live_inferiors () == 1)
puts_filtered (_("Ending remote debugging.\n"));
/* Check to see if we are detaching a fork parent. Note that if we
@@ -5071,10 +5067,11 @@ remote_disconnect (struct target_ops *target, const char *args, int from_tty)
if (args)
error (_("Argument given to \"disconnect\" when remotely debugging."));
- /* Make sure we unpush even the extended remote targets; mourn
- won't do it. So call remote_mourn directly instead of
- target_mourn_inferior. */
- remote_mourn (target);
+ /* Make sure we unpush even the extended remote targets. Calling
+ target_mourn_inferior won't unpush, and remote_mourn won't
+ unpush if there is more than one inferior left. */
+ unpush_target (target);
+ generic_mourn_inferior ();
if (from_tty)
puts_filtered ("Ending remote debugging.\n");
@@ -8800,41 +8797,7 @@ kill_new_fork_children (int pid, struct remote_state *rs)
}
\f
-static void
-remote_kill (struct target_ops *ops)
-{
-
- /* Catch errors so the user can quit from gdb even when we
- aren't on speaking terms with the remote system. */
- TRY
- {
- putpkt ("k");
- }
- CATCH (ex, RETURN_MASK_ERROR)
- {
- if (ex.error == TARGET_CLOSE_ERROR)
- {
- /* If we got an (EOF) error that caused the target
- to go away, then we're done, that's what we wanted.
- "k" is susceptible to cause a premature EOF, given
- that the remote server isn't actually required to
- reply to "k", and it can happen that it doesn't
- even get to reply ACK to the "k". */
- return;
- }
-
- /* Otherwise, something went wrong. We didn't actually kill
- the target. Just propagate the exception, and let the
- user or higher layers decide what to do. */
- throw_exception (ex);
- }
- END_CATCH
-
- /* We've killed the remote end, we get to mourn it. Since this is
- target remote, single-process, mourning the inferior also
- unpushes remote_ops. */
- target_mourn_inferior ();
-}
+/* Send a kill request to the target using the 'vKill' packet. */
static int
remote_vkill (int pid, struct remote_state *rs)
@@ -8861,56 +8824,99 @@ remote_vkill (int pid, struct remote_state *rs)
}
}
+/* Send a kill request to the target using the 'k' packet. */
+
static void
-extended_remote_kill (struct target_ops *ops)
+remote_kill_k (void)
{
- int res;
+ /* Catch errors so the user can quit from gdb even when we
+ aren't on speaking terms with the remote system. */
+ TRY
+ {
+ putpkt ("k");
+ }
+ CATCH (ex, RETURN_MASK_ERROR)
+ {
+ if (ex.error == TARGET_CLOSE_ERROR)
+ {
+ /* If we got an (EOF) error that caused the target
+ to go away, then we're done, that's what we wanted.
+ "k" is susceptible to cause a premature EOF, given
+ that the remote server isn't actually required to
+ reply to "k", and it can happen that it doesn't
+ even get to reply ACK to the "k". */
+ return;
+ }
+
+ /* Otherwise, something went wrong. We didn't actually kill
+ the target. Just propagate the exception, and let the
+ user or higher layers decide what to do. */
+ throw_exception (ex);
+ }
+ END_CATCH
+}
+
+/* Target hook to kill the current inferior. */
+
+static void
+remote_kill (struct target_ops *ops)
+{
+ int res = -1;
int pid = ptid_get_pid (inferior_ptid);
struct remote_state *rs = get_remote_state ();
- /* If we're stopped while forking and we haven't followed yet, kill the
- child task. We need to do this before killing the parent task
- because if this is a vfork then the parent will be sleeping. */
- kill_new_fork_children (pid, rs);
-
- res = remote_vkill (pid, rs);
- if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
+ if (packet_support (PACKET_vKill) != PACKET_DISABLE)
{
- /* Don't try 'k' on a multi-process aware stub -- it has no way
- to specify the pid. */
+ /* If we're stopped while forking and we haven't followed yet,
+ kill the child task. We need to do this before killing the
+ parent task because if this is a vfork then the parent will
+ be sleeping. */
+ kill_new_fork_children (pid, rs);
- putpkt ("k");
-#if 0
- getpkt (&rs->buf, &rs->buf_size, 0);
- if (rs->buf[0] != 'O' || rs->buf[0] != 'K')
- res = 1;
-#else
- /* Don't wait for it to die. I'm not really sure it matters whether
- we do or not. For the existing stubs, kill is a noop. */
- res = 0;
-#endif
+ res = remote_vkill (pid, rs);
+ if (res == 0)
+ {
+ target_mourn_inferior ();
+ return;
+ }
}
- if (res != 0)
- error (_("Can't kill process"));
+ /* If we are in 'target remote' mode and we are killing the only
+ inferior, then we will tell gdbserver to exit and unpush the
+ target. */
+ if (res == -1 && !remote_multi_process_p (rs)
+ && number_of_live_inferiors () == 1)
+ {
+ remote_kill_k ();
- target_mourn_inferior ();
-}
+ /* We've killed the remote end, we get to mourn it. If we are
+ not in extended mode, mourning the inferior also unpushes
+ remote_ops from the target stack, which closes the remote
+ connection. */
+ target_mourn_inferior ();
-static void
-remote_mourn (struct target_ops *target)
-{
- unpush_target (target);
+ return;
+ }
- /* remote_close takes care of doing most of the clean up. */
- generic_mourn_inferior ();
+ error (_("Can't kill process"));
+ return;
}
static void
-extended_remote_mourn (struct target_ops *target)
+remote_mourn (struct target_ops *target)
{
struct remote_state *rs = get_remote_state ();
+ /* In 'target remote' mode with one inferior, we close the connection. */
+ if (!rs->extended && number_of_live_inferiors () <= 1)
+ {
+ unpush_target (target);
+
+ /* remote_close takes care of doing most of the clean up. */
+ generic_mourn_inferior ();
+ return;
+ }
+
/* In case we got here due to an error, but we're going to stay
connected. */
rs->waiting_for_stop_reply = 0;
@@ -8940,10 +8946,7 @@ extended_remote_mourn (struct target_ops *target)
current thread. */
record_currthread (rs, minus_one_ptid);
- /* Unlike "target remote", we do not want to unpush the target; then
- the next time the user says "run", we won't be connected. */
-
- /* Call common code to mark the inferior as not running. */
+ /* Call common code to mark the inferior as not running. */
generic_mourn_inferior ();
if (!have_inferiors ())
@@ -10465,7 +10468,7 @@ remote_pid_to_str (struct target_ops *ops, ptid_t ptid)
{
if (ptid_equal (magic_null_ptid, ptid))
xsnprintf (buf, sizeof buf, "Thread <main>");
- else if (rs->extended && remote_multi_process_p (rs))
+ else if (remote_multi_process_p (rs))
if (ptid_get_lwp (ptid) == 0)
return normal_pid_to_str (ptid);
else
@@ -11635,11 +11638,7 @@ remote_supports_multi_process (struct target_ops *self)
{
struct remote_state *rs = get_remote_state ();
- /* Only extended-remote handles being attached to multiple
- processes, even though plain remote can use the multi-process
- thread id extensions, so that GDB knows the target process's
- PID. */
- return rs->extended && remote_multi_process_p (rs);
+ return remote_multi_process_p (rs);
}
static int
@@ -13071,6 +13070,14 @@ Specify the serial device it is connected to\n\
remote_ops.to_btrace_conf = remote_btrace_conf;
remote_ops.to_augmented_libraries_svr4_read =
remote_augmented_libraries_svr4_read;
+ remote_ops.to_follow_fork = remote_follow_fork;
+ remote_ops.to_follow_exec = remote_follow_exec;
+ remote_ops.to_insert_fork_catchpoint = remote_insert_fork_catchpoint;
+ remote_ops.to_remove_fork_catchpoint = remote_remove_fork_catchpoint;
+ remote_ops.to_insert_vfork_catchpoint = remote_insert_vfork_catchpoint;
+ remote_ops.to_remove_vfork_catchpoint = remote_remove_vfork_catchpoint;
+ remote_ops.to_insert_exec_catchpoint = remote_insert_exec_catchpoint;
+ remote_ops.to_remove_exec_catchpoint = remote_remove_exec_catchpoint;
}
/* Set up the extended remote vector by making a copy of the standard
@@ -13089,27 +13096,11 @@ init_extended_remote_ops (void)
Specify the serial device it is connected to (e.g. /dev/ttya).";
extended_remote_ops.to_open = extended_remote_open;
extended_remote_ops.to_create_inferior = extended_remote_create_inferior;
- extended_remote_ops.to_mourn_inferior = extended_remote_mourn;
extended_remote_ops.to_detach = extended_remote_detach;
extended_remote_ops.to_attach = extended_remote_attach;
extended_remote_ops.to_post_attach = extended_remote_post_attach;
- extended_remote_ops.to_kill = extended_remote_kill;
extended_remote_ops.to_supports_disable_randomization
= extended_remote_supports_disable_randomization;
- extended_remote_ops.to_follow_fork = remote_follow_fork;
- extended_remote_ops.to_follow_exec = remote_follow_exec;
- extended_remote_ops.to_insert_fork_catchpoint
- = remote_insert_fork_catchpoint;
- extended_remote_ops.to_remove_fork_catchpoint
- = remote_remove_fork_catchpoint;
- extended_remote_ops.to_insert_vfork_catchpoint
- = remote_insert_vfork_catchpoint;
- extended_remote_ops.to_remove_vfork_catchpoint
- = remote_remove_vfork_catchpoint;
- extended_remote_ops.to_insert_exec_catchpoint
- = remote_insert_exec_catchpoint;
- extended_remote_ops.to_remove_exec_catchpoint
- = remote_remove_exec_catchpoint;
}
static int
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 0/3] Target remote mode fork and exec support
2015-11-20 13:04 ` Pedro Alves
2015-11-20 16:50 ` Don Breazeal
@ 2015-12-07 22:14 ` Don Breazeal
2015-12-07 22:14 ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
` (3 more replies)
1 sibling, 4 replies; 24+ messages in thread
From: Don Breazeal @ 2015-12-07 22:14 UTC (permalink / raw)
To: gdb-patches
This is an update of the patchset implementing target remote mode
for and exec events. The primary changes from the previous version
are:
* reorder the patches so that the test patch is first
* implement changes requested by Pedro's review of the implementation
patch, primarily rewriting remote_kill.
* minor updates to the documentation patch to eliminate incorrect
characterization of follow-exec-mode as "unsupported" in remote mode.
Details of the changes are outlined in each patch.
Thanks!
--Don
This patchset implements support fork and exec events for target
remote mode Linux targets. This is done primarily by enabling
functionality that had previously been restricted to extended-remote
mode, and by preventing gdbserver from exiting until there are no
more active inferiors left.
There were a number of tests that had to be modified to enable them in
target-remote mode.
The GDB manual sections on connecting to a remote target were modified
and reorganized to clarify the distinction between remote,
extended-remote, and multiprocess, and to collect related information
into subsections.
The patches include:
PATCH 1/3: Enables fork and exec tests for target remote mode.
PATCH 2/3: Implements target remote mode fork and exec event support.
PATCH 3/3: Updates documentation for fork and exec events with target
remote.
Tested on x86_64 Linux with native, remote, and extended-remote. Also
tried it with Pedro's patch that modified gdbserver exit criteria,
https://sourceware.org/ml/gdb-patches/2015-10/msg00222.html, and saw no
regressions.
Thanks, Don
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 1/3] Target remote mode fork and exec tests
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
2015-12-07 22:14 ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
@ 2015-12-07 22:14 ` Don Breazeal
2015-12-08 12:58 ` Pedro Alves
2015-12-07 22:15 ` [PATCH v2 3/3] Target remote mode fork and exec docs Don Breazeal
2015-12-08 13:11 ` [PATCH v2 0/3] Target remote mode fork and exec support Pedro Alves
3 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-12-07 22:14 UTC (permalink / raw)
To: gdb-patches
This is an updated version of the target remote fork/exec event
test changes. The only difference from the previous version of
the patch is that gdb.trace/report.exp was modified to account for
pid.tid style thread numbering.
Thanks
--Don
This patch updates tests for fork and exec events in target remote mode.
In the majority of cases this was a simple matter of removing some
code that disabled the test for target remote. In a few cases the
test needed to be disabled; in those cases the gdb_protocol was checked
instead of using the [is_remote target] etc.
In a couple of cases we needed to use clean_restart, since target remote
doesn't support the run command, and in one case we had to modify an
expect expression to allow for a "multiprocess-style" ptid.
Tested with the patch that implemented target remote mode fork and exec
event support.
gdb/testsuite/
2015-12-07 Don Breazeal <donb@codesourcery.com>
* gdb.base/execl-update-breakpoints.exp (main): Enable for target
remote.
* gdb.base/foll-exec-mode.exp (main): Disable for target remote.
* gdb.base/foll-exec.exp (main): Enable for target remote.
* gdb.base/foll-fork.exp (main): Likewise.
* gdb.base/foll-vfork.exp (main): Likewise.
* gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
(proc continue_to_exit_bp_loc): Use clean_restart.
* gdb.base/pie-execl.exp (main): Disable for target remote.
* gdb.base/watch-vfork.exp (main): Enable for target remote.
* gdb.mi/mi-nsthrexec.exp (main): Likewise.
* gdb.threads/execl.exp (main): Likewise.
* gdb.threads/fork-child-threads.exp (main): Likewise.
* gdb.threads/fork-plus-threads.exp (main): Disable for target
remote.
* gdb.threads/fork-thread-pending.exp (main): Enable for target
remote.
* gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
pid.tid style ptids, instead of just tid.
* gdb.threads/thread-execl.exp (main): Enable for target remote.
* gdb.threads/watchpoint-fork.exp (main): Likewise.
* gdb.trace/report.exp (use_collected_data): Allow pid.tid style
ptids, instead of just tid.
---
gdb/testsuite/gdb.base/execl-update-breakpoints.exp | 6 ------
gdb/testsuite/gdb.base/foll-exec-mode.exp | 8 ++++++--
gdb/testsuite/gdb.base/foll-exec.exp | 4 ----
gdb/testsuite/gdb.base/foll-fork.exp | 4 ----
gdb/testsuite/gdb.base/foll-vfork.exp | 4 ----
gdb/testsuite/gdb.base/multi-forks.exp | 6 ++----
gdb/testsuite/gdb.base/pie-execl.exp | 10 ++++++----
gdb/testsuite/gdb.base/watch-vfork.exp | 5 -----
gdb/testsuite/gdb.mi/mi-nsthrexec.exp | 5 -----
gdb/testsuite/gdb.threads/execl.exp | 4 ----
gdb/testsuite/gdb.threads/fork-child-threads.exp | 4 ----
gdb/testsuite/gdb.threads/fork-plus-threads.exp | 8 ++++++++
gdb/testsuite/gdb.threads/fork-thread-pending.exp | 6 ------
gdb/testsuite/gdb.threads/linux-dp.exp | 4 ++--
gdb/testsuite/gdb.threads/thread-execl.exp | 5 -----
gdb/testsuite/gdb.threads/watchpoint-fork.exp | 5 -----
gdb/testsuite/gdb.trace/report.exp | 2 +-
17 files changed, 25 insertions(+), 65 deletions(-)
diff --git a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
index a980791..20d9101 100644
--- a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
+++ b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
@@ -16,12 +16,6 @@
# Test that when following an exec, we don't try to insert breakpoints
# in the new image at the addresses the symbols had before the exec.
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
-}
-
standard_testfile
# Build two copies of the program, each linked at a different address.
diff --git a/gdb/testsuite/gdb.base/foll-exec-mode.exp b/gdb/testsuite/gdb.base/foll-exec-mode.exp
index ee193e2..5dfe9b5 100644
--- a/gdb/testsuite/gdb.base/foll-exec-mode.exp
+++ b/gdb/testsuite/gdb.base/foll-exec-mode.exp
@@ -26,8 +26,12 @@
# be a breakpoint in order to stop after the exec, even if we use
# a single-step command to execute past the exec.
-if { [is_remote target] || ![isnative] } then {
- continue
+# Remote mode doesn't support the 'run' command, which is
+# required for follow-exec-mode testing.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
}
# Until "catch exec" is implemented on other targets...
diff --git a/gdb/testsuite/gdb.base/foll-exec.exp b/gdb/testsuite/gdb.base/foll-exec.exp
index 0a6347c..a36f212 100644
--- a/gdb/testsuite/gdb.base/foll-exec.exp
+++ b/gdb/testsuite/gdb.base/foll-exec.exp
@@ -16,10 +16,6 @@
# This is a test of gdb's ability to follow a process through a
# Unix exec() system call.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "catch exec" is implemented on other targets...
#
if {![istarget "hppa*-hp-hpux*"] && ![istarget "*-linux*"]} then {
diff --git a/gdb/testsuite/gdb.base/foll-fork.exp b/gdb/testsuite/gdb.base/foll-fork.exp
index 5993973..51e6a7a 100644
--- a/gdb/testsuite/gdb.base/foll-fork.exp
+++ b/gdb/testsuite/gdb.base/foll-fork.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index 82922d8..0659509 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -18,10 +18,6 @@
# either execs or exits --- since those events take somewhat different
# code paths in GDB, both variants are exercised.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/multi-forks.exp b/gdb/testsuite/gdb.base/multi-forks.exp
index 2b0b81d..cb1464d 100644
--- a/gdb/testsuite/gdb.base/multi-forks.exp
+++ b/gdb/testsuite/gdb.base/multi-forks.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
@@ -111,6 +107,7 @@ proc continue_to_exit_bp_loc {} {
# First set gdb to follow the child.
# The result should be that each of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork child"
continue_to_exit_bp_loc
@@ -120,6 +117,7 @@ gdb_test "print pids" "\\$.* = \\{0, 0, 0, 0\\}.*" "follow child, print pids"
# Now set gdb to follow the parent.
# Result should be that none of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork parent" ""
continue_to_exit_bp_loc
diff --git a/gdb/testsuite/gdb.base/pie-execl.exp b/gdb/testsuite/gdb.base/pie-execl.exp
index 51edc82..f75c4dc 100644
--- a/gdb/testsuite/gdb.base/pie-execl.exp
+++ b/gdb/testsuite/gdb.base/pie-execl.exp
@@ -23,10 +23,12 @@ if ![istarget *-linux*] {
continue
}
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
+# In remote mode we cannot use the 'set args' command, and this
+# test requires it.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
}
standard_testfile .c
diff --git a/gdb/testsuite/gdb.base/watch-vfork.exp b/gdb/testsuite/gdb.base/watch-vfork.exp
index 9b43ac6..67ff1c2 100644
--- a/gdb/testsuite/gdb.base/watch-vfork.exp
+++ b/gdb/testsuite/gdb.base/watch-vfork.exp
@@ -15,11 +15,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for vfork events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile .c
if { [build_executable ${testfile}.exp ${testfile} $srcfile {debug}] } {
diff --git a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
index 9ba7739..d55a156 100644
--- a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
+++ b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
@@ -18,11 +18,6 @@
# the main thread doesn't just silently stop at the first internal
# breakpoint (usually the _dl_debug_state breakpoint).
-# No exec event support in the remote protocol.
-if { [is_remote target] } then {
- continue
-}
-
if { ![support_displaced_stepping] } {
unsupported "displaced stepping"
return -1
diff --git a/gdb/testsuite/gdb.threads/execl.exp b/gdb/testsuite/gdb.threads/execl.exp
index b86b612..92e3e81 100644
--- a/gdb/testsuite/gdb.threads/execl.exp
+++ b/gdb/testsuite/gdb.threads/execl.exp
@@ -15,10 +15,6 @@
# Test handling of threads across an execl.
-if { [is_remote target] } then {
- continue
-}
-
# Original image, loads a thread library.
standard_testfile
diff --git a/gdb/testsuite/gdb.threads/fork-child-threads.exp b/gdb/testsuite/gdb.threads/fork-child-threads.exp
index 75e60e1..7c52753 100644
--- a/gdb/testsuite/gdb.threads/fork-child-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-child-threads.exp
@@ -18,10 +18,6 @@ if { ! [istarget "*-*-linux*"] } {
return 0
}
-if { [is_remote target] || ![isnative] } then {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
diff --git a/gdb/testsuite/gdb.threads/fork-plus-threads.exp b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
index 2b34b6c..d5a915b 100644
--- a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
@@ -20,6 +20,14 @@
#
# See https://sourceware.org/bugzilla/show_bug.cgi?id=18600
+# In remote mode, we cannot continue debugging after all
+# inferiors have terminated, and this test requires that.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
+}
+
standard_testfile
proc do_test { detach_on_fork } {
diff --git a/gdb/testsuite/gdb.threads/fork-thread-pending.exp b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
index d229232..ad8adad 100644
--- a/gdb/testsuite/gdb.threads/fork-thread-pending.exp
+++ b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
@@ -13,12 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for `set follow-fork-mode' in the remote
-# protocol.
-if { [is_remote target] } {
- return 0
-}
-
# Only GNU/Linux is known to support `set follow-fork-mode child'.
#
if { ! [istarget "*-*-linux*"] } {
diff --git a/gdb/testsuite/gdb.threads/linux-dp.exp b/gdb/testsuite/gdb.threads/linux-dp.exp
index a089cac..49ff1f7 100644
--- a/gdb/testsuite/gdb.threads/linux-dp.exp
+++ b/gdb/testsuite/gdb.threads/linux-dp.exp
@@ -64,7 +64,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
verbose -log "found thread $expect_out(1,string)" 2
lappend threads_before $expect_out(1,string)
exp_continue
@@ -126,7 +126,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
set name $expect_out(1,string)
for {set j 0} {$j != [llength $threads_before] } {incr j} {
if {$name == [lindex $threads_before $j]} {
diff --git a/gdb/testsuite/gdb.threads/thread-execl.exp b/gdb/testsuite/gdb.threads/thread-execl.exp
index a598ad0..8df6a15 100644
--- a/gdb/testsuite/gdb.threads/thread-execl.exp
+++ b/gdb/testsuite/gdb.threads/thread-execl.exp
@@ -16,11 +16,6 @@
# Test that GDB doesn't get stuck when stepping over an exec call done
# by a thread other than the main thread.
-# There's no support for exec events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
diff --git a/gdb/testsuite/gdb.threads/watchpoint-fork.exp b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
index a4557f8..2fd1517 100644
--- a/gdb/testsuite/gdb.threads/watchpoint-fork.exp
+++ b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
@@ -17,11 +17,6 @@
set testfile watchpoint-fork
-if [is_remote target] {
- kfail "remote/13584" "gdbserver does not support debugging across fork"
- return
-}
-
proc test {type symbol} {
with_test_prefix "$type" {
global testfile subdir srcdir gdb_prompt
diff --git a/gdb/testsuite/gdb.trace/report.exp b/gdb/testsuite/gdb.trace/report.exp
index 53ea943..28bf715 100644
--- a/gdb/testsuite/gdb.trace/report.exp
+++ b/gdb/testsuite/gdb.trace/report.exp
@@ -386,7 +386,7 @@ proc use_collected_data { data_source } {
# There is always a thread of an inferior, either a live one or
# a faked one.
- gdb_test "info threads" "\\* ${decimal} (process|Thread) ${decimal}\[ \t\].*"
+ gdb_test "info threads" "\\* ${decimal} (process|Thread) \[0-9\.\]+\[ \t\].*"
gdb_test "info inferiors" "\\* 1 process ${decimal} \[ \t\]+${binfile}.*"
}
}
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH v2 3/3] Target remote mode fork and exec docs
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
2015-12-07 22:14 ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
2015-12-07 22:14 ` [PATCH v2 1/3] Target remote mode fork and exec tests Don Breazeal
@ 2015-12-07 22:15 ` Don Breazeal
2015-12-08 13:07 ` Pedro Alves
2015-12-08 13:11 ` [PATCH v2 0/3] Target remote mode fork and exec support Pedro Alves
3 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-12-07 22:15 UTC (permalink / raw)
To: gdb-patches
This is version two of a patch that updates the documentation for
fork and exec event support in target remote mode. Most of the
changes in this version are those requested by Eli in a previous
review
(https://sourceware.org/ml/gdb-patches/2015-11/msg00278.html).
Those issues included: start table item text with capital letter,
be consistent with empty lines after @item lines, be consistent
in use of @code and @kbd, and fix a couple of @pxref problems.
All of those are dealt with in this version.
In addition, I made a minor change to the text in both the NEWS and
gdb.texinfo files, modifying "follow-exec-mode is not supported in
target remote mode" to say instead that follow-exec-mode is of limited
usefulness in that mode since the 'run' command is not supported there.
Thanks!
--Don
This patch implements documentation updates for target remote mode
fork and exec events. A summary of the rationale for the changes
made here:
* Connecting to a remote target -- explain that the two protocols exist.
* Connecting in target remote mode -- explain invoking gdbserver for
target remote mode, and move remote-specific text from original
"Connecting to a remote target" section.
* Connecting in target extended-remote mode -- promote this section
from "Using the gdbserver Program | Running gdbserver | Multi-Process Mode
for gdbserver". Put it next to the target remote mode section.
* Host and target files -- collect paragraphs dealing with how to locate
symbol files from original sections "Connecting to a remote target" and
"Using the gdbserver program | Connecting to gdbserver".
* Steps for connecting to a remote target -- used to be "Using the
gdbserver program | Connecting to gdbserver"
* Remote connection commands -- used to be the bulk of "Connecting to a
remote target". Added "target extended-remote" commands and information.
gdb/
2015-12-07 Don Breazeal <donb@sourceware.org>
* NEWS: Announce fork and exec event support for target remote.
gdb/doc/
2015-12-07 Don Breazeal <donb@sourceware.org>
* gdb.texinfo (Forks): Correct Linux kernel version where
fork and exec events are supported, add notes about support
of these events in target remote mode.
(Connecting): Reorganize and clarify distinctions between
target remote, extended-remote, and multiprocess.
Reorganize related text from separate sections into new
sections.
(Server): Note effects of target extended-remote mode.
Delete section on Multi-Process Mode for gdbserver.
Move some text to "Connecting" node.
---
gdb/NEWS | 9 ++
gdb/doc/gdb.texinfo | 268 +++++++++++++++++++++++++++++++++++++---------------
2 files changed, 200 insertions(+), 77 deletions(-)
diff --git a/gdb/NEWS b/gdb/NEWS
index a222dfb..bec9810 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -127,6 +127,15 @@ show remote exec-event-feature-packet
The reply to qXfer:threads:read may now include a name attribute for each
thread.
+* Target remote mode fork and exec events
+
+ ** GDB now has support for fork and exec events on target remote mode
+ Linux targets. For such targets with Linux kernels 2.5.46 and later,
+ this enables follow-fork-mode, detach-on-fork, follow-exec-mode, and
+ fork and exec catchpoints. Note that follow-exec-mode is of limited
+ usefulness, because target remote mode does not support the 'run'
+ command.
+
*** Changes in GDB 7.10
* Support for process record-replay and reverse debugging on aarch64*-linux*
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index b82f3c6..5b60231 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -3133,10 +3133,11 @@ the child process just like any other process which you attached to.
On some systems, @value{GDBN} provides support for debugging programs that
create additional processes using the @code{fork} or @code{vfork} functions.
Currently, the only platforms with this feature are HP-UX (11.x and later
-only?) and @sc{gnu}/Linux (kernel version 2.5.60 and later).
+only?) and @sc{gnu}/Linux (kernel version 2.5.46 and later).
-The fork debugging commands are supported in both native mode and when
-connected to @code{gdbserver} using @kbd{target extended-remote}.
+The fork debugging commands are supported in native mode and when
+connected to @code{gdbserver} in either @code{target remote} mode or
+@code{target extended-remote} mode.
By default, when a program forks, @value{GDBN} will continue to debug
the parent process and the child process will run unimpeded.
@@ -3282,6 +3283,11 @@ Program exited normally.
@end table
@end table
+@code{follow-exec-mode} is supported in native mode and
+@code{target extended-remote} mode. It is of limited usefulness in
+@code{target remote} mode since the run command is not supported in that
+mode.
+
You can use the @code{catch} command to make @value{GDBN} stop whenever
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting Catchpoints}.
@@ -19234,28 +19240,148 @@ configuration of @value{GDBN}; use @code{help target} to list them.
@node Connecting
@section Connecting to a Remote Target
+@cindex remote debugging, connecting
+@cindex @code{gdbserver}, connecting
+@cindex remote debugging, types of connections
+@cindex @code{gdbserver}, types of connections
+@cindex @code{gdbserver}, @code{target remote} mode
+@cindex @code{gdbserver}, @code{target extended-remote} mode
+
+This section describes how to connect to a remote target, including the
+types of connections and their differences, how to set up executable and
+symbol files on the host and target, and the commands used for
+connecting to and disconnecting from the remote target.
+
+@subsection Types of Remote Connections
+
+@value{GDBN} supports two types of remote connections, @code{target remote}
+mode and @code{target extended-remote} mode. Note that many remote targets
+support only @code{target remote} mode. There are several major
+differences between the two types of connections, enumerated here:
+
+@table @asis
-@value{GDBN} needs an unstripped copy of your program to access symbol
-and debugging information. Some remote targets (@pxref{qXfer
-executable filename read}, and @pxref{Host I/O Packets}) allow
-@value{GDBN} to access program files over the same connection used to
-communicate with @value{GDBN}. With such a target, if the remote
-program is unstripped, the only command you need is @code{target
-remote}. Otherwise, start up @value{GDBN} using the name of the local
+@cindex remote debugging, detach and program exit
+@item Result of detach or program exit
+@strong{With target remote mode:} When the debugged program exits or you
+detach from it, @value{GDBN} disconnects from the target. When using
+@code{gdbserver}, @code{gdbserver} will exit.
+
+@strong{With target extended-remote mode:} When the debugged program exits or
+you detach from it, @value{GDBN} remains connected to the target, even
+though no program is running. You can rerun the program, attach to a
+running program, or use @code{monitor} commands specific to the target.
+
+When using @code{gdbserver} in this case, it does not exit unless it was
+invoked using the @option{--once} option. If the @option{--once} option
+was not used, you can ask @code{gdbserver} to exit using the
+@code{monitor exit} command (@pxref{Monitor Commands for gdbserver}).
+
+@item Specifying the program to debug
+For both connection types you use the @code{file} command to specify the
+program on the host system. If you are using @code{gdbserver} there are
+some differences in how to specify the location of the program on the
+target.
+
+@strong{With target remote mode:} You must either specify the program to debug
+on the @code{gdbserver} command line or use the @option{--attach} option
+(@pxref{Attaching to a program,,Attaching to a Running Program}).
+
+@cindex @option{--multi}, @code{gdbserver} option
+@strong{With target extended-remote mode:} You may specify the program to debug
+on the @code{gdbserver} command line, or you can load the program or attach
+to it using @value{GDBN} commands after connecting to @code{gdbserver}.
+
+@anchor{--multi Option in Types of Remote Connnections}
+You can start @code{gdbserver} without supplying an initial command to run
+or process ID to attach. To do this, use the @option{--multi} command line
+option. Then you can connect using @code{target extended-remote} and start
+the program you want to debug (see below for details on using the
+@code{run} command in this scenario). Note that the conditions under which
+@code{gdbserver} terminates depend on how @value{GDBN} connects to it
+(@code{target remote} or @code{target extended-remote}). The
+@option{--multi} option to @code{gdbserver} has no influence on that.
+
+@item The @code{run} command
+@strong{With target remote mode:} The @code{run} command is not
+supported. Once a connection has been established, you can use all
+the usual @value{GDBN} commands to examine and change data. The
+remote program is already running, so you can use commands like
+@kbd{step} and @kbd{continue}.
+
+@strong{With target extended-remote mode:} The @code{run} command is
+supported. The @code{run} command uses the value set by
+@code{set remote exec-file} (@pxref{set remote exec-file}) to select
+the program to run. Command line arguments are supported, except for
+wildcard expansion and I/O redirection (@pxref{Arguments}).
+
+If you specify the program to debug on the command line, then the
+@code{run} command is not required to start execution, and you can
+resume using commands like @kbd{step} and @kbd{continue} as with
+@code{target remote} mode.
+
+@anchor{Attaching in Types of Remote Connections}
+@item Attaching
+@strong{With target remote mode:} The @value{GDBN} command @code{attach} is
+not supported. To attach to a running program using @code{gdbserver}, you
+must use the @option{--attach} option (@pxref{Running gdbserver}).
+
+@strong{With target extended-remote mode:} To attach to a running program,
+you may use the @code{attach} command after the connection has been
+established. If you are using @code{gdbserver}, you may also invoke
+@code{gdbserver} using the @option{--attach} option
+(@pxref{Running gdbserver}).
+
+@end table
+
+@anchor{Host and target files}
+@subsection Host and Target Files
+@cindex remote debugging, symbol files
+@cindex symbol files, remote debugging
+
+@value{GDBN}, running on the host, needs access to symbol and debugging
+information for your program running on the target. This requires
+access to an unstripped copy of your program, and possibly any associated
+symbol files. Note that this section applies equally to both @code{target
+remote} mode and @code{target extended-remote} mode.
+
+Some remote targets (@pxref{qXfer executable filename read}, and
+@pxref{Host I/O Packets}) allow @value{GDBN} to access program files over
+the same connection used to communicate with @value{GDBN}. With such a
+target, if the remote program is unstripped, the only command you need is
+@code{target remote} (or @code{target extended-remote}).
+
+If the remote program is stripped, or the target does not support remote
+program file access, start up @value{GDBN} using the name of the local
unstripped copy of your program as the first argument, or use the
-@code{file} command.
+@code{file} command. Use @code{set sysroot} to specify the location (on
+the host) of target libraries (unless your @value{GDBN} was compiled with
+the correct sysroot using @code{--with-sysroot}). Alternatively, you
+may use @code{set solib-search-path} to specify how @value{GDBN} locates
+target libraries.
-@cindex @code{target remote}
+The symbol file and target libraries must exactly match the executable
+and libraries on the target, with one exception: the files on the host
+system should not be stripped, even if the files on the target system
+are. Mismatched or missing files will lead to confusing results
+during debugging. On @sc{gnu}/Linux targets, mismatched or missing
+files may also prevent @code{gdbserver} from debugging multi-threaded
+programs.
+
+@subsection Remote Connection Commands
+@cindex remote connection commands
@value{GDBN} can communicate with the target over a serial line, or
over an @acronym{IP} network using @acronym{TCP} or @acronym{UDP}. In
each case, @value{GDBN} uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
-@code{target remote} command establishes a connection to the target.
-Its arguments indicate which medium to use:
+@code{target remote} and @code{target extended-remote} commands
+establish a connection to the target. Both commands accept the same
+arguments, which indicate the medium to use:
@table @code
@item target remote @var{serial-device}
+@itemx target extended-remote @var{serial-device}
@cindex serial line, @code{target remote}
Use @var{serial-device} to communicate with the target. For example,
to use a serial line connected to the device named @file{/dev/ttyb}:
@@ -19271,6 +19397,8 @@ If you're using a serial line, you may want to give @value{GDBN} the
@item target remote @code{@var{host}:@var{port}}
@itemx target remote @code{tcp:@var{host}:@var{port}}
+@itemx target extended-remote @code{@var{host}:@var{port}}
+@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
@cindex @acronym{TCP} port, @code{target remote}
Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
The @var{host} may be either a host name or a numeric @acronym{IP}
@@ -19299,6 +19427,7 @@ target remote :1234
Note that the colon is still required here.
@item target remote @code{udp:@var{host}:@var{port}}
+@itemx target extended-remote @code{udp:@var{host}:@var{port}}
@cindex @acronym{UDP} port, @code{target remote}
Debug using @acronym{UDP} packets to @var{port} on @var{host}. For example, to
connect to @acronym{UDP} port 2828 on a terminal server named @code{manyfarms}:
@@ -19313,6 +19442,7 @@ can silently drop packets on busy or unreliable networks, which will
cause havoc with your debugging session.
@item target remote | @var{command}
+@itemx target extended-remote | @var{command}
@cindex pipe, @code{target remote} to
Run @var{command} in the background and communicate with it using a
pipe. The @var{command} is a shell command, to be parsed and expanded
@@ -19328,11 +19458,6 @@ program has already exited, this will have no effect.)
@end table
-Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use @kbd{step} and @kbd{continue}, and you do not
-need to use @kbd{run}.
-
@cindex interrupting remote programs
@cindex remote programs, interrupting
Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -19346,10 +19471,13 @@ Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n)
@end smallexample
-If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
-remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
-goes back to waiting.
+In @code{target remote} mode, if you type @kbd{y}, @value{GDBN} abandons
+the remote debugging session. (If you decide you want to try again later,
+you can use @kbd{target remote} again to connect once more.) If you type
+@kbd{n}, @value{GDBN} goes back to waiting.
+
+In @code{target extended-remote} mode, typing @kbd{n} will leave
+@value{GDBN} connected to the target.
@table @code
@kindex detach (remote)
@@ -19358,11 +19486,13 @@ When you have finished debugging the remote program, you can use the
@code{detach} command to release it from @value{GDBN} control.
Detaching from the target normally resumes its execution, but the results
will depend on your particular remote stub. After the @code{detach}
-command, @value{GDBN} is free to connect to another target.
+command in @code{target remote} mode, @value{GDBN} is free to connect to
+another target. In @code{target extended-remote} mode, @value{GDBN} is
+still connected to the target.
@kindex disconnect
@item disconnect
-The @code{disconnect} command behaves like @code{detach}, except that
+The @code{disconnect} command closes the connection to the target, and
the target is generally not resumed. It will wait for @value{GDBN}
(this instance or another one) to connect and continue debugging. After
the @code{disconnect} command, @value{GDBN} is again free to connect to
@@ -19419,7 +19549,8 @@ Delete @var{targetfile} from the target system.
@cindex remote connection without stubs
@code{gdbserver} is a control program for Unix-like systems, which
allows you to connect your program with a remote @value{GDBN} via
-@code{target remote}---but without linking in the usual debugging stub.
+@code{target remote} or @code{target extended-remote}---but without
+linking in the usual debugging stub.
@code{gdbserver} is not a complete replacement for the debugging stubs,
because it requires essentially the same operating-system facilities
@@ -19447,6 +19578,7 @@ target system with the same privileges as the user running
@code{gdbserver}.
@end quotation
+@anchor{Running gdbserver}
@subsection Running @code{gdbserver}
@cindex arguments, to @code{gdbserver}
@cindex @code{gdbserver}, command-line arguments
@@ -19514,6 +19646,7 @@ Programs started with stdio-connected gdbserver have @file{/dev/null} for
display through a pipe connected to gdbserver.
Both @code{stdout} and @code{stderr} use the same pipe.
+@anchor{Attaching to a program}
@subsubsection Attaching to a Running Program
@cindex attach to a program, @code{gdbserver}
@cindex @option{--attach}, @code{gdbserver} option
@@ -19525,8 +19658,12 @@ This is accomplished via the @code{--attach} argument. The syntax is:
target> gdbserver --attach @var{comm} @var{pid}
@end smallexample
-@var{pid} is the process ID of a currently running process. It isn't necessary
-to point @code{gdbserver} at a binary for the running process.
+@var{pid} is the process ID of a currently running process. It isn't
+necessary to point @code{gdbserver} at a binary for the running process.
+
+In @code{target extended-remote} mode, you can also attach using the
+@value{GDBN} attach command
+(@pxref{Attaching in Types of Remote Connections}).
@pindex pidof
You can debug processes by name instead of process ID if your target has the
@@ -19540,41 +19677,10 @@ In case more than one copy of @var{program} is running, or @var{program}
has multiple threads, most versions of @code{pidof} support the
@code{-s} option to only return the first process ID.
-@subsubsection Multi-Process Mode for @code{gdbserver}
-@cindex @code{gdbserver}, multiple processes
-@cindex multiple processes with @code{gdbserver}
-
-When you connect to @code{gdbserver} using @code{target remote},
-@code{gdbserver} debugs the specified program only once. When the
-program exits, or you detach from it, @value{GDBN} closes the connection
-and @code{gdbserver} exits.
-
-If you connect using @kbd{target extended-remote}, @code{gdbserver}
-enters multi-process mode. When the debugged program exits, or you
-detach from it, @value{GDBN} stays connected to @code{gdbserver} even
-though no program is running. The @code{run} and @code{attach}
-commands instruct @code{gdbserver} to run or attach to a new program.
-The @code{run} command uses @code{set remote exec-file} (@pxref{set
-remote exec-file}) to select the program to run. Command line
-arguments are supported, except for wildcard expansion and I/O
-redirection (@pxref{Arguments}).
-
-@cindex @option{--multi}, @code{gdbserver} option
-To start @code{gdbserver} without supplying an initial command to run
-or process ID to attach, use the @option{--multi} command line option.
-Then you can connect using @kbd{target extended-remote} and start
-the program you want to debug.
-
-In multi-process mode @code{gdbserver} does not automatically exit unless you
-use the option @option{--once}. You can terminate it by using
-@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note that the
-conditions under which @code{gdbserver} terminates depend on how @value{GDBN}
-connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
-@option{--multi} option to @code{gdbserver} has no influence on that.
-
@subsubsection TCP port allocation lifecycle of @code{gdbserver}
-This section applies only when @code{gdbserver} is run to listen on a TCP port.
+This section applies only when @code{gdbserver} is run to listen on a TCP
+port.
@code{gdbserver} normally terminates after all of its debugged processes have
terminated in @kbd{target remote} mode. On the other hand, for @kbd{target
@@ -19605,6 +19711,12 @@ instance closes its port after the first connection.
@anchor{Other Command-Line Arguments for gdbserver}
@subsubsection Other Command-Line Arguments for @code{gdbserver}
+You can use the @option{--multi} option to start @code{gdbserver} without
+specifying a program to debug or a process to attach to. Then you can
+attach in @code{target extended-remote} mode and run or attach to a
+program. For more information,
+@pxref{--multi Option in Types of Remote Connnections}.
+
@cindex @option{--debug}, @code{gdbserver} option
The @option{--debug} option tells @code{gdbserver} to display extra
status information about the debugging process.
@@ -19656,32 +19768,34 @@ $ gdbserver --wrapper env LD_PRELOAD=libtest.so -- :2222 ./testprog
@subsection Connecting to @code{gdbserver}
-Run @value{GDBN} on the host system.
+The basic procedure for connecting to the remote target is:
+@itemize
-First make sure you have the necessary symbol files. Load symbols for
-your application using the @code{file} command before you connect. Use
-@code{set sysroot} to locate target libraries (unless your @value{GDBN}
-was compiled with the correct sysroot using @code{--with-sysroot}).
+@item
+Run @value{GDBN} on the host system.
-The symbol file and target libraries must exactly match the executable
-and libraries on the target, with one exception: the files on the host
-system should not be stripped, even if the files on the target system
-are. Mismatched or missing files will lead to confusing results
-during debugging. On @sc{gnu}/Linux targets, mismatched or missing
-files may also prevent @code{gdbserver} from debugging multi-threaded
-programs.
+@item
+Make sure you have the necessary symbol files
+(@pxref{Host and target files}).
+Load symbols for your application using the @code{file} command before you
+connect. Use @code{set sysroot} to locate target libraries (unless your
+@value{GDBN} was compiled with the correct sysroot using
+@code{--with-sysroot}).
+@item
Connect to your target (@pxref{Connecting,,Connecting to a Remote Target}).
For TCP connections, you must start up @code{gdbserver} prior to using
-the @code{target remote} command. Otherwise you may get an error whose
+the @code{target} command. Otherwise you may get an error whose
text depends on the host system, but which usually looks something like
@samp{Connection refused}. Don't use the @code{load}
-command in @value{GDBN} when using @code{gdbserver}, since the program is
-already on the target.
+command in @value{GDBN} when using @code{target remote} mode, since the
+program is already on the target.
+
+@end itemize
+@anchor{Monitor Commands for gdbserver}
@subsection Monitor Commands for @code{gdbserver}
@cindex monitor commands, for @code{gdbserver}
-@anchor{Monitor Commands for gdbserver}
During a @value{GDBN} session using @code{gdbserver}, you can use the
@code{monitor} command to send special requests to @code{gdbserver}.
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 2/3] Target remote mode fork and exec events
2015-12-07 22:14 ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
@ 2015-12-08 12:55 ` Pedro Alves
2015-12-14 19:29 ` Don Breazeal
0 siblings, 1 reply; 24+ messages in thread
From: Pedro Alves @ 2015-12-08 12:55 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
On 12/07/2015 10:14 PM, Don Breazeal wrote:
> On 11/20/2015 5:04 AM, Pedro Alves wrote:
>>> Note that follow-exec-mode is not supported, because target
>>> remote mode does not support the 'run' command.
>>
>> Not sure I don't understand this part/comment.
>
> As I noted in my previous reply, this was an overly-pessimistic way of
> putting it. I revised the docs etc to say something like this:
> "follow-exec-mode is of limited used in target remote mode, since the 'run'
> command is not supported." The point being that the main reason a user
> would want to set follow-exec-mode would be to get control over which
> inferior is run when a 'run' command is executed. It is supported in
> that the inferiors are created or not created as specified, and one could
> (for example) use follow-exec-mode to keep a record of the programs that
> were executed.
Right. Note that we could support "run" with "target remote", as long
as the remote side supports vRun. The problem with simply enabling
"run" is that:
(gdb) target remote
...
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n)
... saying yes will kill the inferior and close the connection, before
there's a chance to start the new process...
But, with "set detach-on-fork off", say the program forks, and then the child
execs, and then it exits. The parent is still running so the "target remote"
connection is still up. Switch to the child inferior (inferior 2), and
issue "run". I can see people wondering why that doesn't work.
Likewise the simpler:
(gdb) target remote ...
*inferior 1 is now bound to progress N (the only process) running on the target*
(gdb) add-inferior
*inferior 2 added*
(gdb) inferior 2
(gdb) run
Should we allow that "run" to actually succeed in this case?
((((
Actually trying the detach-on-fork scenario above, we see very
confusing behavior (this is with your series, but I think
current master will have similar problems):
$ gdb -ex "tar rem :9999"
0x0000003615a011f0 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) set detach-on-fork off
(gdb) c
Continuing.
Reading /lib64/libm.so.6 from remote target...
Reading /lib64/libc.so.6 from remote target...
[New Thread 32274.32274]
Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
Reading /lib64/libm.so.6 from remote target...
Reading /lib64/libc.so.6 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
[Inferior 1 (process 32258) exited normally]
Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
(gdb) info inferiors
Num Description Executable
* 1 <null> target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
2 process 32274 target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
(gdb) maint print target-stack
The current target stack is:
- remote (Remote serial target in gdb-specific protocol)
- exec (Local exec file)
- None (None)
(gdb) run
Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
`target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork' has disappeared; keeping its symbols.
Starting program: target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
Detaching after fork from child process 32279.
/bin/bash: /home/pedro/gdb/mygit/build/gdb/target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork: No such file or directory
During startup program exited with code 127.
(gdb) maint print target-stack
The current target stack is:
- exec (Local exec file)
- None (None)
(gdb)
Note that that last run tried to create the inferior in the
native target and its the native target that silently closes
the remote connection...:
(top-gdb) bt
#0 remote_close (self=0xdde300 <remote_ops>) at /home/pedro/gdb/mygit/src/gdb/remote.c:3403
#1 0x0000000000696101 in target_close (targ=0xdde300 <remote_ops>) at /home/pedro/gdb/mygit/src/gdb/target.c:3308
#2 0x0000000000691e8d in push_target (t=0xece890) at /home/pedro/gdb/mygit/src/gdb/target.c:697
#3 0x00000000004b9495 in inf_ptrace_create_inferior (ops=0xece890, exec_file=0x1bfa190 "target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork",
allargs=0x1c09f60 "", env=0x12d0220, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/inf-ptrace.c:105
#4 0x00000000004bf6dc in linux_nat_create_inferior (ops=0xece890, exec_file=0x1bfa190 "target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork",
allargs=0x1c09f60 "", env=0x12d0220, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/linux-nat.c:1194
#5 0x000000000062c018 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at /home/pedro/gdb/mygit/src/gdb/infcmd.c:604
#6 0x000000000062c121 in run_command (args=0x0, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/infcmd.c:639
I tried the "add-inferior" scenario too now, and it's also
quite confusing:
(gdb) info inferiors
Num Description Executable
* 1 process 32274 target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
(gdb) add-inferior
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork...done.
(gdb) set remote exec-file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
(gdb) start
Temporary breakpoint 1 at 0x400671: main. (2 locations)
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
Detaching after fork from child process 32353.
Detaching after fork from child process 32354.
Detaching after fork from child process 32356.
Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
[Inferior 2 (process 32353) exited normally]
(gdb) info inferiors
Num Description Executable
1 <null> target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
* 2 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
(gdb) maint print target-stack
The current target stack is:
- exec (Local exec file)
- None (None)
(gdb)
Likewise here start closed the remote connection, and then
find_run_target() returns the native target.
"set auto-connect-native-target off" works around these issues.
))))
> Tested on x86_64 native, native-gdbserver, native-extended-gdbserver. No
> regressions, other than one issue with gdb.reverse/waitpid-reverse.exp.
> My version of GDB seemed to evoke an existing KFAIL, and after that I
> would get a new FAIL. I didn't see the KFAIL on "master", and so the
> subsequent FAIL wouldn't show up either.
Sorry, I'm confused. Does this series cause a new FAIL, or not?
>
> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
> index 5e053b3..2e0e1d5 100644
> --- a/gdb/gdbserver/server.c
> +++ b/gdb/gdbserver/server.c
> @@ -3959,9 +3959,11 @@ process_serial_event (void)
> discard_queued_stop_replies (pid_to_ptid (pid));
> write_ok (own_buf);
>
> - if (extended_protocol)
> + if (extended_protocol || get_first_inferior (&all_threads) != NULL)
Replace that get_first_inferior() by get_first_thread() or even target_running().
> @@ -8800,41 +8797,7 @@ kill_new_fork_children (int pid, struct remote_state *rs)
> }
>
> \f
> -static void
> -remote_kill (struct target_ops *ops)
> -{
> -
> - /* Catch errors so the user can quit from gdb even when we
> - aren't on speaking terms with the remote system. */
> - TRY
> - {
> - putpkt ("k");
> - }
> - CATCH (ex, RETURN_MASK_ERROR)
> - {
> - if (ex.error == TARGET_CLOSE_ERROR)
> - {
> - /* If we got an (EOF) error that caused the target
> - to go away, then we're done, that's what we wanted.
> - "k" is susceptible to cause a premature EOF, given
> - that the remote server isn't actually required to
> - reply to "k", and it can happen that it doesn't
> - even get to reply ACK to the "k". */
> - return;
> - }
> -
> - /* Otherwise, something went wrong. We didn't actually kill
> - the target. Just propagate the exception, and let the
> - user or higher layers decide what to do. */
> - throw_exception (ex);
> - }
> - END_CATCH
> -
> - /* We've killed the remote end, we get to mourn it. Since this is
> - target remote, single-process, mourning the inferior also
> - unpushes remote_ops. */
> - target_mourn_inferior ();
> -}
> +/* Send a kill request to the target using the 'vKill' packet. */
>
> static int
> remote_vkill (int pid, struct remote_state *rs)
> @@ -8861,56 +8824,99 @@ remote_vkill (int pid, struct remote_state *rs)
> }
> }
>
> +/* Send a kill request to the target using the 'k' packet. */
> +
> static void
> -extended_remote_kill (struct target_ops *ops)
> +remote_kill_k (void)
> {
> - int res;
> + /* Catch errors so the user can quit from gdb even when we
> + aren't on speaking terms with the remote system. */
> + TRY
> + {
> + putpkt ("k");
> + }
> + CATCH (ex, RETURN_MASK_ERROR)
> + {
> + if (ex.error == TARGET_CLOSE_ERROR)
> + {
> + /* If we got an (EOF) error that caused the target
> + to go away, then we're done, that's what we wanted.
> + "k" is susceptible to cause a premature EOF, given
> + that the remote server isn't actually required to
> + reply to "k", and it can happen that it doesn't
> + even get to reply ACK to the "k". */
> + return;
> + }
> +
> + /* Otherwise, something went wrong. We didn't actually kill
> + the target. Just propagate the exception, and let the
> + user or higher layers decide what to do. */
> + throw_exception (ex);
> + }
> + END_CATCH
> +}
Can't tell why you moved the function below rather than rename it
in place. I suspect that it was just a consequence of how v1 was
written. If there's no reason for the move, please leave the function
where it was (and check for spurious changes afterwards), which helps
git blame archaeology.
> +
> +/* Target hook to kill the current inferior. */
> +
> +static void
> +remote_kill (struct target_ops *ops)
> +{
> -static void
> -remote_mourn (struct target_ops *target)
> -{
> - unpush_target (target);
> + return;
> + }
>
> - /* remote_close takes care of doing most of the clean up. */
> - generic_mourn_inferior ();
> + error (_("Can't kill process"));
> + return;
"return" is unreachable after "error".
Otherwise looks good to me.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 1/3] Target remote mode fork and exec tests
2015-12-07 22:14 ` [PATCH v2 1/3] Target remote mode fork and exec tests Don Breazeal
@ 2015-12-08 12:58 ` Pedro Alves
2015-12-14 19:29 ` [pushed] " Don Breazeal
0 siblings, 1 reply; 24+ messages in thread
From: Pedro Alves @ 2015-12-08 12:58 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
On 12/07/2015 10:14 PM, Don Breazeal wrote:
> +# In remote mode we cannot use the 'set args' command, and this
> +# test requires it.
> +if { [target_info exists gdb_protocol] } then {
> + if { [target_info gdb_protocol] == "remote" } then {
> + continue
> + }
> }
>
It looks a little odd to me not to merge that into a single if:
if { [target_info exists gdb_protocol]
&& [target_info gdb_protocol] == "remote" } {
continue
}
> if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
> diff --git a/gdb/testsuite/gdb.threads/fork-plus-threads.exp b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
> index 2b34b6c..d5a915b 100644
> --- a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
> +++ b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
> @@ -20,6 +20,14 @@
> #
> # See https://sourceware.org/bugzilla/show_bug.cgi?id=18600
>
> +# In remote mode, we cannot continue debugging after all
> +# inferiors have terminated, and this test requires that.
> +if { [target_info exists gdb_protocol] } then {
> + if { [target_info gdb_protocol] == "remote" } then {
> + continue
> + }
> +}
Likewise.
In any case, this is OK.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 3/3] Target remote mode fork and exec docs
2015-12-07 22:15 ` [PATCH v2 3/3] Target remote mode fork and exec docs Don Breazeal
@ 2015-12-08 13:07 ` Pedro Alves
2015-12-14 19:30 ` [pushed] " Don Breazeal
0 siblings, 1 reply; 24+ messages in thread
From: Pedro Alves @ 2015-12-08 13:07 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
On 12/07/2015 10:14 PM, Don Breazeal wrote:
> diff --git a/gdb/NEWS b/gdb/NEWS
> index a222dfb..bec9810 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -127,6 +127,15 @@ show remote exec-event-feature-packet
> The reply to qXfer:threads:read may now include a name attribute for each
> thread.
>
> +* Target remote mode fork and exec events
> +
> + ** GDB now has support for fork and exec events on target remote mode
> + Linux targets. For such targets with Linux kernels 2.5.46 and later,
> + this enables follow-fork-mode, detach-on-fork, follow-exec-mode, and
> + fork and exec catchpoints. Note that follow-exec-mode is of limited
> + usefulness, because target remote mode does not support the 'run'
> + command.
...
>
> +@code{follow-exec-mode} is supported in native mode and
> +@code{target extended-remote} mode. It is of limited usefulness in
> +@code{target remote} mode since the run command is not supported in that
> +mode.
Thinking about this some more, I'm really not sure we should be calling out
this limited usefulness here (and NEWS). It seems just as useful in
remote mode -- it's just that when you want to restart the debugging from
the starting binary, you do "target remote" again instead of "run" then.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 0/3] Target remote mode fork and exec support
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
` (2 preceding siblings ...)
2015-12-07 22:15 ` [PATCH v2 3/3] Target remote mode fork and exec docs Don Breazeal
@ 2015-12-08 13:11 ` Pedro Alves
3 siblings, 0 replies; 24+ messages in thread
From: Pedro Alves @ 2015-12-08 13:11 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
On 12/07/2015 10:14 PM, Don Breazeal wrote:
> This is an update of the patchset implementing target remote mode
> for and exec events. The primary changes from the previous version
> are:
> * reorder the patches so that the test patch is first
> * implement changes requested by Pedro's review of the implementation
> patch, primarily rewriting remote_kill.
> * minor updates to the documentation patch to eliminate incorrect
> characterization of follow-exec-mode as "unsupported" in remote mode.
>
> Details of the changes are outlined in each patch.
>
Thanks!
> (...) Also
> tried it with Pedro's patch that modified gdbserver exit criteria,
> https://sourceware.org/ml/gdb-patches/2015-10/msg00222.html, and saw no
> regressions.
(Note this is in master now.)
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
* [pushed] Re: [PATCH v2 1/3] Target remote mode fork and exec tests
2015-12-08 12:58 ` Pedro Alves
@ 2015-12-14 19:29 ` Don Breazeal
0 siblings, 0 replies; 24+ messages in thread
From: Don Breazeal @ 2015-12-14 19:29 UTC (permalink / raw)
To: Pedro Alves, Breazeal, Don, gdb-patches
On 12/8/2015 4:58 AM, Pedro Alves wrote:
> On 12/07/2015 10:14 PM, Don Breazeal wrote:
>
>> +# In remote mode we cannot use the 'set args' command, and this
>> +# test requires it.
>> +if { [target_info exists gdb_protocol] } then {
>> + if { [target_info gdb_protocol] == "remote" } then {
>> + continue
>> + }
>> }
>>
>
> It looks a little odd to me not to merge that into a single if:
>
> if { [target_info exists gdb_protocol]
> && [target_info gdb_protocol] == "remote" } {
> continue
> }
>
>
>> if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
>> diff --git a/gdb/testsuite/gdb.threads/fork-plus-threads.exp b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
>> index 2b34b6c..d5a915b 100644
>> --- a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
>> +++ b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
>> @@ -20,6 +20,14 @@
>> #
>> # See https://sourceware.org/bugzilla/show_bug.cgi?id=18600
>>
>> +# In remote mode, we cannot continue debugging after all
>> +# inferiors have terminated, and this test requires that.
>> +if { [target_info exists gdb_protocol] } then {
>> + if { [target_info gdb_protocol] == "remote" } then {
>> + continue
>> + }
>> +}
>
> Likewise.
I made both of the changes suggested above.
>
> In any case, this is OK.
>
> Thanks,
> Pedro Alves
>
This is now pushed. The updated patch is attached.
From: Don Breazeal <donb@codesourcery.com>
Subject: [pushed][PATCH v3 1/3] Target remote mode fork and exec tests
This is the version of the patch that was pushed. This version is
identical to v2 except for changing:
if { [target_info exists gdb_protocol] } then {
if { [target_info gdb_protocol] == "remote" } then {
continue
}
}
to
if { [target_info exists gdb_protocol]
&& [target_info gdb_protocol] == "remote" } {
continue
}
in gdb.base/foll-exec-mode.exp and gdb.threads/fork-plus-threads.exp.
Here is the commit message:
This patch updates tests for fork and exec events in target remote mode.
In the majority of cases this was a simple matter of removing some code
that disabled the test for target remote. In a few cases the test needed
to be disabled; in those cases the gdb_protocol was checked instead of
using the [is_remote target] etc.
In a couple of cases we needed to use clean_restart, since target remote
doesn't support the run command, and in one case we had to modify an expect
expression to allow for a "multiprocess-style" ptid.
Tested with the patch that implemented target remote mode fork and exec
event support.
gdb/testsuite/ChangeLog:
* gdb.base/execl-update-breakpoints.exp (main): Enable for target
remote.
* gdb.base/foll-exec-mode.exp (main): Disable for target remote.
* gdb.base/foll-exec.exp (main): Enable for target remote.
* gdb.base/foll-fork.exp (main): Likewise.
* gdb.base/foll-vfork.exp (main): Likewise.
* gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
(proc continue_to_exit_bp_loc): Use clean_restart.
* gdb.base/pie-execl.exp (main): Disable for target remote.
* gdb.base/watch-vfork.exp (main): Enable for target remote.
* gdb.mi/mi-nsthrexec.exp (main): Likewise.
* gdb.threads/execl.exp (main): Likewise.
* gdb.threads/fork-child-threads.exp (main): Likewise.
* gdb.threads/fork-plus-threads.exp (main): Disable for target
remote.
* gdb.threads/fork-thread-pending.exp (main): Enable for target
remote.
* gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
pid.tid style ptids, instead of just tid.
* gdb.threads/thread-execl.exp (main): Enable for target remote.
* gdb.threads/watchpoint-fork.exp (main): Likewise.
* gdb.trace/report.exp (use_collected_data): Allow pid.tid style
ptids, instead of just tid.
---
gdb/testsuite/ChangeLog | 26
++++++++++++++++++++++
.../gdb.base/execl-update-breakpoints.exp | 6 -----
gdb/testsuite/gdb.base/foll-exec-mode.exp | 7 ++++--
gdb/testsuite/gdb.base/foll-exec.exp | 4 ----
gdb/testsuite/gdb.base/foll-fork.exp | 4 ----
gdb/testsuite/gdb.base/foll-vfork.exp | 4 ----
gdb/testsuite/gdb.base/multi-forks.exp | 6 ++---
gdb/testsuite/gdb.base/pie-execl.exp | 10 +++++----
gdb/testsuite/gdb.base/watch-vfork.exp | 5 -----
gdb/testsuite/gdb.mi/mi-nsthrexec.exp | 5 -----
gdb/testsuite/gdb.threads/execl.exp | 4 ----
gdb/testsuite/gdb.threads/fork-child-threads.exp | 4 ----
gdb/testsuite/gdb.threads/fork-plus-threads.exp | 7 ++++++
gdb/testsuite/gdb.threads/fork-thread-pending.exp | 6 -----
gdb/testsuite/gdb.threads/linux-dp.exp | 4 ++--
gdb/testsuite/gdb.threads/thread-execl.exp | 5 -----
gdb/testsuite/gdb.threads/watchpoint-fork.exp | 5 -----
gdb/testsuite/gdb.trace/report.exp | 2 +-
18 files changed, 49 insertions(+), 65 deletions(-)
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index df8c768..f8e7084 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,29 @@
+2015-12-11 Don Breazeal <donb@codesourcery.com>
+
+ * gdb.base/execl-update-breakpoints.exp (main): Enable for target
+ remote.
+ * gdb.base/foll-exec-mode.exp (main): Disable for target remote.
+ * gdb.base/foll-exec.exp (main): Enable for target remote.
+ * gdb.base/foll-fork.exp (main): Likewise.
+ * gdb.base/foll-vfork.exp (main): Likewise.
+ * gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
+ (proc continue_to_exit_bp_loc): Use clean_restart.
+ * gdb.base/pie-execl.exp (main): Disable for target remote.
+ * gdb.base/watch-vfork.exp (main): Enable for target remote.
+ * gdb.mi/mi-nsthrexec.exp (main): Likewise.
+ * gdb.threads/execl.exp (main): Likewise.
+ * gdb.threads/fork-child-threads.exp (main): Likewise.
+ * gdb.threads/fork-plus-threads.exp (main): Disable for target
+ remote.
+ * gdb.threads/fork-thread-pending.exp (main): Enable for target
+ remote.
+ * gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
+ pid.tid style ptids, instead of just tid.
+ * gdb.threads/thread-execl.exp (main): Enable for target remote.
+ * gdb.threads/watchpoint-fork.exp (main): Likewise.
+ * gdb.trace/report.exp (use_collected_data): Allow pid.tid style
+ ptids, instead of just tid.
+
2015-12-11 Andrew Burgess <andrew.burgess@embecosm.com>
* gdb.base/list.exp (test_list_forward): Add end of file error
diff --git a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
index a980791..20d9101 100644
--- a/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
+++ b/gdb/testsuite/gdb.base/execl-update-breakpoints.exp
@@ -16,12 +16,6 @@
# Test that when following an exec, we don't try to insert breakpoints
# in the new image at the addresses the symbols had before the exec.
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
-}
-
standard_testfile
# Build two copies of the program, each linked at a different address.
diff --git a/gdb/testsuite/gdb.base/foll-exec-mode.exp
b/gdb/testsuite/gdb.base/foll-exec-mode.exp
index ee193e2..8a0a3a9 100644
--- a/gdb/testsuite/gdb.base/foll-exec-mode.exp
+++ b/gdb/testsuite/gdb.base/foll-exec-mode.exp
@@ -26,8 +26,11 @@
# be a breakpoint in order to stop after the exec, even if we use
# a single-step command to execute past the exec.
-if { [is_remote target] || ![isnative] } then {
- continue
+# Remote mode doesn't support the 'run' command, which is
+# required for follow-exec-mode testing.
+if { [target_info exists gdb_protocol]
+ && [target_info gdb_protocol] == "remote" } {
+ continue
}
# Until "catch exec" is implemented on other targets...
diff --git a/gdb/testsuite/gdb.base/foll-exec.exp
b/gdb/testsuite/gdb.base/foll-exec.exp
index 0a6347c..a36f212 100644
--- a/gdb/testsuite/gdb.base/foll-exec.exp
+++ b/gdb/testsuite/gdb.base/foll-exec.exp
@@ -16,10 +16,6 @@
# This is a test of gdb's ability to follow a process through a
# Unix exec() system call.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "catch exec" is implemented on other targets...
#
if {![istarget "hppa*-hp-hpux*"] && ![istarget "*-linux*"]} then {
diff --git a/gdb/testsuite/gdb.base/foll-fork.exp
b/gdb/testsuite/gdb.base/foll-fork.exp
index 5993973..51e6a7a 100644
--- a/gdb/testsuite/gdb.base/foll-fork.exp
+++ b/gdb/testsuite/gdb.base/foll-fork.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp
b/gdb/testsuite/gdb.base/foll-vfork.exp
index 82922d8..0659509 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -18,10 +18,6 @@
# either execs or exits --- since those events take somewhat different
# code paths in GDB, both variants are exercised.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
diff --git a/gdb/testsuite/gdb.base/multi-forks.exp
b/gdb/testsuite/gdb.base/multi-forks.exp
index 2b0b81d..cb1464d 100644
--- a/gdb/testsuite/gdb.base/multi-forks.exp
+++ b/gdb/testsuite/gdb.base/multi-forks.exp
@@ -13,10 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-if { [is_remote target] || ![isnative] } then {
- continue
-}
-
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
@@ -111,6 +107,7 @@ proc continue_to_exit_bp_loc {} {
# First set gdb to follow the child.
# The result should be that each of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork child"
continue_to_exit_bp_loc
@@ -120,6 +117,7 @@ gdb_test "print pids" "\\$.* = \\{0, 0, 0, 0\\}.*"
"follow child, print pids"
# Now set gdb to follow the parent.
# Result should be that none of the 4 forks returns zero.
+clean_restart ${binfile}
runto_main
gdb_test_no_output "set follow-fork parent" ""
continue_to_exit_bp_loc
diff --git a/gdb/testsuite/gdb.base/pie-execl.exp
b/gdb/testsuite/gdb.base/pie-execl.exp
index 51edc82..f75c4dc 100644
--- a/gdb/testsuite/gdb.base/pie-execl.exp
+++ b/gdb/testsuite/gdb.base/pie-execl.exp
@@ -23,10 +23,12 @@ if ![istarget *-linux*] {
continue
}
-# Remote protocol does not support follow-exec notifications.
-
-if [is_remote target] {
- continue
+# In remote mode we cannot use the 'set args' command, and this
+# test requires it.
+if { [target_info exists gdb_protocol] } then {
+ if { [target_info gdb_protocol] == "remote" } then {
+ continue
+ }
}
standard_testfile .c
diff --git a/gdb/testsuite/gdb.base/watch-vfork.exp
b/gdb/testsuite/gdb.base/watch-vfork.exp
index 9b43ac6..67ff1c2 100644
--- a/gdb/testsuite/gdb.base/watch-vfork.exp
+++ b/gdb/testsuite/gdb.base/watch-vfork.exp
@@ -15,11 +15,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for vfork events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile .c
if { [build_executable ${testfile}.exp ${testfile} $srcfile {debug}] } {
diff --git a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
index 9ba7739..d55a156 100644
--- a/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
+++ b/gdb/testsuite/gdb.mi/mi-nsthrexec.exp
@@ -18,11 +18,6 @@
# the main thread doesn't just silently stop at the first internal
# breakpoint (usually the _dl_debug_state breakpoint).
-# No exec event support in the remote protocol.
-if { [is_remote target] } then {
- continue
-}
-
if { ![support_displaced_stepping] } {
unsupported "displaced stepping"
return -1
diff --git a/gdb/testsuite/gdb.threads/execl.exp
b/gdb/testsuite/gdb.threads/execl.exp
index b86b612..92e3e81 100644
--- a/gdb/testsuite/gdb.threads/execl.exp
+++ b/gdb/testsuite/gdb.threads/execl.exp
@@ -15,10 +15,6 @@
# Test handling of threads across an execl.
-if { [is_remote target] } then {
- continue
-}
-
# Original image, loads a thread library.
standard_testfile
diff --git a/gdb/testsuite/gdb.threads/fork-child-threads.exp
b/gdb/testsuite/gdb.threads/fork-child-threads.exp
index 75e60e1..7c52753 100644
--- a/gdb/testsuite/gdb.threads/fork-child-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-child-threads.exp
@@ -18,10 +18,6 @@ if { ! [istarget "*-*-linux*"] } {
return 0
}
-if { [is_remote target] || ![isnative] } then {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}"
executable {debug}] != "" } {
diff --git a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
index 2b34b6c..fe88a51 100644
--- a/gdb/testsuite/gdb.threads/fork-plus-threads.exp
+++ b/gdb/testsuite/gdb.threads/fork-plus-threads.exp
@@ -20,6 +20,13 @@
#
# See https://sourceware.org/bugzilla/show_bug.cgi?id=18600
+# In remote mode, we cannot continue debugging after all
+# inferiors have terminated, and this test requires that.
+if { [target_info exists gdb_protocol]
+ && [target_info gdb_protocol] == "remote" } {
+ continue
+}
+
standard_testfile
proc do_test { detach_on_fork } {
diff --git a/gdb/testsuite/gdb.threads/fork-thread-pending.exp
b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
index d229232..ad8adad 100644
--- a/gdb/testsuite/gdb.threads/fork-thread-pending.exp
+++ b/gdb/testsuite/gdb.threads/fork-thread-pending.exp
@@ -13,12 +13,6 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# There's no support for `set follow-fork-mode' in the remote
-# protocol.
-if { [is_remote target] } {
- return 0
-}
-
# Only GNU/Linux is known to support `set follow-fork-mode child'.
#
if { ! [istarget "*-*-linux*"] } {
diff --git a/gdb/testsuite/gdb.threads/linux-dp.exp
b/gdb/testsuite/gdb.threads/linux-dp.exp
index a089cac..49ff1f7 100644
--- a/gdb/testsuite/gdb.threads/linux-dp.exp
+++ b/gdb/testsuite/gdb.threads/linux-dp.exp
@@ -64,7 +64,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
verbose -log "found thread $expect_out(1,string)" 2
lappend threads_before $expect_out(1,string)
exp_continue
@@ -126,7 +126,7 @@ for {set i 0} {$i < 5} {incr i} {
-re "^ *Id.*Frame *\[\r\n\]+" {
exp_continue
}
- -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx\]+) \[^\n\]*\n" {
+ -re "^. +(\[0-9\]+ *Thread \[-0-9a-fx.\]+) \[^\n\]*\n" {
set name $expect_out(1,string)
for {set j 0} {$j != [llength $threads_before] } {incr j} {
if {$name == [lindex $threads_before $j]} {
diff --git a/gdb/testsuite/gdb.threads/thread-execl.exp
b/gdb/testsuite/gdb.threads/thread-execl.exp
index a598ad0..8df6a15 100644
--- a/gdb/testsuite/gdb.threads/thread-execl.exp
+++ b/gdb/testsuite/gdb.threads/thread-execl.exp
@@ -16,11 +16,6 @@
# Test that GDB doesn't get stuck when stepping over an exec call done
# by a thread other than the main thread.
-# There's no support for exec events in the remote protocol.
-if { [is_remote target] } {
- return 0
-}
-
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
diff --git a/gdb/testsuite/gdb.threads/watchpoint-fork.exp
b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
index a4557f8..2fd1517 100644
--- a/gdb/testsuite/gdb.threads/watchpoint-fork.exp
+++ b/gdb/testsuite/gdb.threads/watchpoint-fork.exp
@@ -17,11 +17,6 @@
set testfile watchpoint-fork
-if [is_remote target] {
- kfail "remote/13584" "gdbserver does not support debugging across fork"
- return
-}
-
proc test {type symbol} {
with_test_prefix "$type" {
global testfile subdir srcdir gdb_prompt
diff --git a/gdb/testsuite/gdb.trace/report.exp
b/gdb/testsuite/gdb.trace/report.exp
index 53ea943..28bf715 100644
--- a/gdb/testsuite/gdb.trace/report.exp
+++ b/gdb/testsuite/gdb.trace/report.exp
@@ -386,7 +386,7 @@ proc use_collected_data { data_source } {
# There is always a thread of an inferior, either a live one or
# a faked one.
- gdb_test "info threads" "\\* ${decimal} (process|Thread)
${decimal}\[ \t\].*"
+ gdb_test "info threads" "\\* ${decimal} (process|Thread)
\[0-9\.\]+\[ \t\].*"
gdb_test "info inferiors" "\\* 1 process ${decimal} \[
\t\]+${binfile}.*"
}
}
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 2/3] Target remote mode fork and exec events
2015-12-08 12:55 ` Pedro Alves
@ 2015-12-14 19:29 ` Don Breazeal
2015-12-15 10:52 ` Pedro Alves
0 siblings, 1 reply; 24+ messages in thread
From: Don Breazeal @ 2015-12-14 19:29 UTC (permalink / raw)
To: Pedro Alves, gdb-patches
On 12/8/2015 4:55 AM, Pedro Alves wrote:
> On 12/07/2015 10:14 PM, Don Breazeal wrote:
>
>> On 11/20/2015 5:04 AM, Pedro Alves wrote:
>
>>>> Note that follow-exec-mode is not supported, because target
>>>> remote mode does not support the 'run' command.
>>>
>>> Not sure I don't understand this part/comment.
>>
>> As I noted in my previous reply, this was an overly-pessimistic way of
>> putting it. I revised the docs etc to say something like this:
>> "follow-exec-mode is of limited used in target remote mode, since the 'run'
>> command is not supported." The point being that the main reason a user
>> would want to set follow-exec-mode would be to get control over which
>> inferior is run when a 'run' command is executed. It is supported in
>> that the inferiors are created or not created as specified, and one could
>> (for example) use follow-exec-mode to keep a record of the programs that
>> were executed.
>
> Right. Note that we could support "run" with "target remote", as long
> as the remote side supports vRun. The problem with simply enabling
> "run" is that:
>
> (gdb) target remote
> ...
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n)
>
> ... saying yes will kill the inferior and close the connection, before
> there's a chance to start the new process...
>
>
> But, with "set detach-on-fork off", say the program forks, and then the child
> execs, and then it exits. The parent is still running so the "target remote"
> connection is still up. Switch to the child inferior (inferior 2), and
> issue "run". I can see people wondering why that doesn't work.
>
> Likewise the simpler:
>
> (gdb) target remote ...
> *inferior 1 is now bound to progress N (the only process) running on the target*
> (gdb) add-inferior
> *inferior 2 added*
> (gdb) inferior 2
> (gdb) run
>
> Should we allow that "run" to actually succeed in this case?
I'm a believer in "either it always works, or it never works".
>
>
> ((((
> Actually trying the detach-on-fork scenario above, we see very
> confusing behavior (this is with your series, but I think
> current master will have similar problems):
>
> $ gdb -ex "tar rem :9999"
> 0x0000003615a011f0 in _start () from target:/lib64/ld-linux-x86-64.so.2
> (gdb) set detach-on-fork off
> (gdb) c
> Continuing.
> Reading /lib64/libm.so.6 from remote target...
> Reading /lib64/libc.so.6 from remote target...
> [New Thread 32274.32274]
> Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
> Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
> Reading /lib64/libm.so.6 from remote target...
> Reading /lib64/libc.so.6 from remote target...
> Reading /lib64/ld-linux-x86-64.so.2 from remote target...
> Reading /lib64/ld-linux-x86-64.so.2 from remote target...
> [Inferior 1 (process 32258) exited normally]
> Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
> (gdb) info inferiors
> Num Description Executable
> * 1 <null> target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> 2 process 32274 target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> (gdb) maint print target-stack
> The current target stack is:
> - remote (Remote serial target in gdb-specific protocol)
> - exec (Local exec file)
> - None (None)
> (gdb) run
> Reading /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork from remote target...
> `target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork' has disappeared; keeping its symbols.
> Starting program: target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> Detaching after fork from child process 32279.
> /bin/bash: /home/pedro/gdb/mygit/build/gdb/target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork: No such file or directory
> During startup program exited with code 127.
> (gdb) maint print target-stack
> The current target stack is:
> - exec (Local exec file)
> - None (None)
> (gdb)
>
>
> Note that that last run tried to create the inferior in the
> native target and its the native target that silently closes
> the remote connection...:
>
> (top-gdb) bt
> #0 remote_close (self=0xdde300 <remote_ops>) at /home/pedro/gdb/mygit/src/gdb/remote.c:3403
> #1 0x0000000000696101 in target_close (targ=0xdde300 <remote_ops>) at /home/pedro/gdb/mygit/src/gdb/target.c:3308
> #2 0x0000000000691e8d in push_target (t=0xece890) at /home/pedro/gdb/mygit/src/gdb/target.c:697
> #3 0x00000000004b9495 in inf_ptrace_create_inferior (ops=0xece890, exec_file=0x1bfa190 "target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork",
> allargs=0x1c09f60 "", env=0x12d0220, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/inf-ptrace.c:105
> #4 0x00000000004bf6dc in linux_nat_create_inferior (ops=0xece890, exec_file=0x1bfa190 "target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork",
> allargs=0x1c09f60 "", env=0x12d0220, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/linux-nat.c:1194
> #5 0x000000000062c018 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at /home/pedro/gdb/mygit/src/gdb/infcmd.c:604
> #6 0x000000000062c121 in run_command (args=0x0, from_tty=1) at /home/pedro/gdb/mygit/src/gdb/infcmd.c:639
>
>
>
> I tried the "add-inferior" scenario too now, and it's also
> quite confusing:
>
> (gdb) info inferiors
> Num Description Executable
> * 1 process 32274 target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> (gdb) add-inferior
> Added inferior 2
> (gdb) inferior 2
> [Switching to inferior 2 [<null>] (<noexec>)]
> (gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork...done.
> (gdb) set remote exec-file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> (gdb) start
> Temporary breakpoint 1 at 0x400671: main. (2 locations)
> Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> Detaching after fork from child process 32353.
> Detaching after fork from child process 32354.
> Detaching after fork from child process 32356.
> Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
> Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
> Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
> Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
> Error in re-setting breakpoint 1: Cannot access memory at address 0x400669
> [Inferior 2 (process 32353) exited normally]
> (gdb) info inferiors
> Num Description Executable
> 1 <null> target:/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> * 2 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.base/foll-fork
> (gdb) maint print target-stack
> The current target stack is:
> - exec (Local exec file)
> - None (None)
> (gdb)
>
> Likewise here start closed the remote connection, and then
> find_run_target() returns the native target.
>
> "set auto-connect-native-target off" works around these issues.
>
> ))))
Wow. I have a backlog of new tests that we've talked about related to
the fork/exec event support. I can likely make some other tests out of
the above as well.
>
>> Tested on x86_64 native, native-gdbserver, native-extended-gdbserver. No
>> regressions, other than one issue with gdb.reverse/waitpid-reverse.exp.
>> My version of GDB seemed to evoke an existing KFAIL, and after that I
>> would get a new FAIL. I didn't see the KFAIL on "master", and so the
>> subsequent FAIL wouldn't show up either.
>
> Sorry, I'm confused. Does this series cause a new FAIL, or not?
Sorry about the gibberish. It is a FAIL that didn't occur with target
remote mode before, but now it behaves identically to how native and
extended-remote behave by generating the FAIL.
>
>>
>> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
>> index 5e053b3..2e0e1d5 100644
>> --- a/gdb/gdbserver/server.c
>> +++ b/gdb/gdbserver/server.c
>> @@ -3959,9 +3959,11 @@ process_serial_event (void)
>> discard_queued_stop_replies (pid_to_ptid (pid));
>> write_ok (own_buf);
>>
>> - if (extended_protocol)
>> + if (extended_protocol || get_first_inferior (&all_threads) != NULL)
>
> Replace that get_first_inferior() by get_first_thread() or even target_running().
Done.
>
>
>
>> @@ -8800,41 +8797,7 @@ kill_new_fork_children (int pid, struct remote_state *rs)
>> }
>>
>> \f
>> -static void
>> -remote_kill (struct target_ops *ops)
>> -{
>> -
>> - /* Catch errors so the user can quit from gdb even when we
>> - aren't on speaking terms with the remote system. */
>> - TRY
>> - {
>> - putpkt ("k");
>> - }
>> - CATCH (ex, RETURN_MASK_ERROR)
>> - {
>> - if (ex.error == TARGET_CLOSE_ERROR)
>> - {
>> - /* If we got an (EOF) error that caused the target
>> - to go away, then we're done, that's what we wanted.
>> - "k" is susceptible to cause a premature EOF, given
>> - that the remote server isn't actually required to
>> - reply to "k", and it can happen that it doesn't
>> - even get to reply ACK to the "k". */
>> - return;
>> - }
>> -
>> - /* Otherwise, something went wrong. We didn't actually kill
>> - the target. Just propagate the exception, and let the
>> - user or higher layers decide what to do. */
>> - throw_exception (ex);
>> - }
>> - END_CATCH
>> -
>> - /* We've killed the remote end, we get to mourn it. Since this is
>> - target remote, single-process, mourning the inferior also
>> - unpushes remote_ops. */
>> - target_mourn_inferior ();
>> -}
>> +/* Send a kill request to the target using the 'vKill' packet. */
>>
>> static int
>> remote_vkill (int pid, struct remote_state *rs)
>> @@ -8861,56 +8824,99 @@ remote_vkill (int pid, struct remote_state *rs)
>> }
>> }
>>
>> +/* Send a kill request to the target using the 'k' packet. */
>> +
>> static void
>> -extended_remote_kill (struct target_ops *ops)
>> +remote_kill_k (void)
>> {
>> - int res;
>> + /* Catch errors so the user can quit from gdb even when we
>> + aren't on speaking terms with the remote system. */
>> + TRY
>> + {
>> + putpkt ("k");
>> + }
>> + CATCH (ex, RETURN_MASK_ERROR)
>> + {
>> + if (ex.error == TARGET_CLOSE_ERROR)
>> + {
>> + /* If we got an (EOF) error that caused the target
>> + to go away, then we're done, that's what we wanted.
>> + "k" is susceptible to cause a premature EOF, given
>> + that the remote server isn't actually required to
>> + reply to "k", and it can happen that it doesn't
>> + even get to reply ACK to the "k". */
>> + return;
>> + }
>> +
>> + /* Otherwise, something went wrong. We didn't actually kill
>> + the target. Just propagate the exception, and let the
>> + user or higher layers decide what to do. */
>> + throw_exception (ex);
>> + }
>> + END_CATCH
>> +}
>
> Can't tell why you moved the function below rather than rename it
> in place. I suspect that it was just a consequence of how v1 was
> written. If there's no reason for the move, please leave the function
> where it was (and check for spurious changes afterwards), which helps
> git blame archaeology.
This is back in place.
>
>> +
>> +/* Target hook to kill the current inferior. */
>> +
>> +static void
>> +remote_kill (struct target_ops *ops)
>> +{
>
>
>> -static void
>> -remote_mourn (struct target_ops *target)
>> -{
>> - unpush_target (target);
>> + return;
>> + }
>>
>> - /* remote_close takes care of doing most of the clean up. */
>> - generic_mourn_inferior ();
>> + error (_("Can't kill process"));
>> + return;
>
> "return" is unreachable after "error".
Fixed.
>
> Otherwise looks good to me.
>
> Thanks,
> Pedro Alves
>
In testing after making the changes above I ran into a failure I hadn't
seen before, which turned out to be an uninitialized variable that had
been exposed by the new functionality. That resulted in this valgrind
output:
==12133== Invalid free() / delete / delete[] / realloc()
==12133== at 0x4C2BDEC: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12133== by 0x7943FF: xfree (common-utils.c:100)
==12133== by 0x4D0DEE: free_private_thread_info (remote.c:457)
==12133== by 0x62F0A2: free_thread (thread.c:200)
==12133== by 0x62F8DF: delete_thread_1 (thread.c:464)
==12133== by 0x62F93B: delete_thread_silent (thread.c:480)
==12133== by 0x783386: delete_thread_of_inferior (inferior.c:189)
==12133== by 0x62FA2E: iterate_over_threads (thread.c:531)
==12133== by 0x7834EF: exit_inferior_1 (inferior.c:250)
==12133== by 0x7835EC: exit_inferior_silent (inferior.c:288)
==12133== by 0x7836DE: discard_all_inferiors (inferior.c:328)
==12133== by 0x4D5D3C: remote_close (remote.c:3432)
==12133== Address 0x746e69206669206b is not stack'd, malloc'd or
(recently) free'd
I've included the fix in my commit as obvious:
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1918,7 +1918,8 @@ demand_private_info (ptid_t ptid)
info->priv = XNEW (struct private_thread_info);
info->private_dtor = free_private_thread_info;
info->priv->core = -1;
- info->priv->extra = 0;
+ info->priv->extra = NULL;
+ info->priv->name = NULL;
This is now pushed; the updated patch is attached.
I think with this, basic remote fork and exec events are complete. I
appreciate all your help with this project, Pedro. Thanks for hanging
in there with me!
--Don
From: Don Breazeal <donb@codesourcery.com>
Subject: [pushed][PATCH v3 2/3] Target remote mode fork and exec events
This is the version of the patch that was pushed. The only differences
from v2 are:
* server.c:process_serial_event, use target_running instead of
get_first_inferior
* replace remote_kill in its original location in remote.c
* remote.c:remote_kill, remove unreachable "return"
I also ran into an intermittent failure that was caused by an
uninitialized variable, exposed by the new functionality. I just
included the change here as obvious:
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1918,7 +1918,8 @@ demand_private_info (ptid_t ptid)
info->priv = XNEW (struct private_thread_info);
info->private_dtor = free_private_thread_info;
info->priv->core = -1;
- info->priv->extra = 0;
+ info->priv->extra = NULL;
+ info->priv->name = NULL;
Here is the commit message:
This patch implements support for fork and exec events with target remote
mode Linux targets. For such targets with Linux kernels 2.5.46 and later,
this enables follow-fork-mode, detach-on-fork and fork and exec
catchpoints.
The changes required to implement this included:
* Don't exit from gdbserver if there are still active inferiors.
* Allow changing the active process in remote mode.
* Enable fork and exec events in remote mode.
* Print "Ending remote debugging" only when disconnecting.
* Combine remote_kill and extended_remote_kill into a single function
that can handle the multiple inferior case for target remote. Also,
the same thing for remote_mourn and extended_remote_mourn.
* Enable process-style ptids in target remote.
* Remove restriction on multiprocess mode in target remote.
gdb/gdbserver/ChangeLog:
* server.c (process_serial_event): Don't exit from gdbserver
in remote mode if there are still active inferiors.
gdb/ChangeLog:
* inferior.c (number_of_live_inferiors): New function.
(have_live_inferiors): Use number_of_live_inferiors in place
of duplicate code.
* inferior.h (number_of_live_inferiors): Declare new function.
* remote.c (set_general_process): Remove restriction on target
remote mode.
(remote_query_supported): Likewise.
(remote_detach_1): Exit in target remote mode only when there
is just one live inferior left.
(remote_disconnect): Unpush the target directly instead of
calling remote_mourn.
(remote_kill): Rewrite function to handle both target remote
and extended-remote. Call remote_kill_k.
(remote_kill_k): New function.
(extended_remote_kill): Delete function.
(remote_mourn, extended_remote_mourn): Combine functions into
one, remote_mourn, and enable extended functionality for target
remote.
(remote_pid_to_str): Enable "process" style ptid string for
target remote.
(remote_supports_multi_process): Remove restriction on target
remote mode.
---
gdb/ChangeLog | 25 ++++++
gdb/gdbserver/ChangeLog | 5 ++
gdb/gdbserver/server.c | 6 +-
gdb/inferior.c | 31 ++++++--
gdb/inferior.h | 3 +
gdb/remote.c | 205
+++++++++++++++++++++++-------------------------
6 files changed, 161 insertions(+), 114 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index f9ed66d..9ded377 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,28 @@
+2015-12-11 Don Breazeal <donb@codesourcery.com>
+
+ * inferior.c (number_of_live_inferiors): New function.
+ (have_live_inferiors): Use number_of_live_inferiors in place
+ of duplicate code.
+ * inferior.h (number_of_live_inferiors): Declare new function.
+ * remote.c (set_general_process): Remove restriction on target
+ remote mode.
+ (remote_query_supported): Likewise.
+ (remote_detach_1): Exit in target remote mode only when there
+ is just one live inferior left.
+ (remote_disconnect): Unpush the target directly instead of
+ calling remote_mourn.
+ (remote_kill): Rewrite function to handle both target remote
+ and extended-remote. Call remote_kill_k.
+ (remote_kill_k): New function.
+ (extended_remote_kill): Delete function.
+ (remote_mourn, extended_remote_mourn): Combine functions into
+ one, remote_mourn, and enable extended functionality for target
+ remote.
+ (remote_pid_to_str): Enable "process" style ptid string for
+ target remote.
+ (remote_supports_multi_process): Remove restriction on target
+ remote mode.
+
2015-12-14 Andrew Burgess <andrew.burgess@embecosm.com>
* i386-tdep.c (i386_mpx_info_bounds): Use TYPE_LENGTH.
diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog
index 617c249..63bb250 100644
--- a/gdb/gdbserver/ChangeLog
+++ b/gdb/gdbserver/ChangeLog
@@ -1,3 +1,8 @@
+2015-12-11 Don Breazeal <donb@codesourcery.com>
+
+ * server.c (process_serial_event): Don't exit from gdbserver
+ in remote mode if there are still active inferiors.
+
2015-12-11 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_breakpoint_at): Call
diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index a09841c..8f097e5 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -3959,9 +3959,11 @@ process_serial_event (void)
discard_queued_stop_replies (pid_to_ptid (pid));
write_ok (own_buf);
- if (extended_protocol)
+ if (extended_protocol || target_running ())
{
- /* Treat this like a normal program exit. */
+ /* There is still at least one inferior remaining or
+ we are in extended mode, so don't terminate gdbserver,
+ and instead treat this like a normal program exit. */
last_status.kind = TARGET_WAITKIND_EXITED;
last_status.value.integer = 0;
last_ptid = pid_to_ptid (pid);
diff --git a/gdb/inferior.c b/gdb/inferior.c
index 157e236..a0296c8 100644
--- a/gdb/inferior.c
+++ b/gdb/inferior.c
@@ -459,22 +459,41 @@ have_inferiors (void)
return 0;
}
+/* Return the number of live inferiors. We account for the case
+ where an inferior might have a non-zero pid but no threads, as
+ in the middle of a 'mourn' operation. */
+
int
-have_live_inferiors (void)
+number_of_live_inferiors (void)
{
struct inferior *inf;
+ int num_inf = 0;
for (inf = inferior_list; inf; inf = inf->next)
if (inf->pid != 0)
{
struct thread_info *tp;
-
- tp = any_thread_of_process (inf->pid);
- if (tp && target_has_execution_1 (tp->ptid))
- break;
+
+ ALL_NON_EXITED_THREADS (tp)
+ if (tp && ptid_get_pid (tp->ptid) == inf->pid)
+ if (target_has_execution_1 (tp->ptid))
+ {
+ /* Found a live thread in this inferior, go to the next
+ inferior. */
+ ++num_inf;
+ break;
+ }
}
- return inf != NULL;
+ return num_inf;
+}
+
+/* Return true if there is at least one live inferior. */
+
+int
+have_live_inferiors (void)
+{
+ return number_of_live_inferiors () > 0;
}
/* Prune away any unused inferiors, and then prune away no longer used
diff --git a/gdb/inferior.h b/gdb/inferior.h
index d3cf615..78a5ed3 100644
--- a/gdb/inferior.h
+++ b/gdb/inferior.h
@@ -490,6 +490,9 @@ extern struct inferior *iterate_over_inferiors (int
(*) (struct inferior *,
/* Returns true if the inferior list is not empty. */
extern int have_inferiors (void);
+/* Returns the number of live inferiors (real live processes). */
+extern int number_of_live_inferiors (void);
+
/* Returns true if there are any live inferiors in the inferior list
(not cores, not executables, real live processes). */
extern int have_live_inferiors (void);
diff --git a/gdb/remote.c b/gdb/remote.c
index 52c5df8..1190522 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -119,12 +119,12 @@ struct remote_state;
static int remote_vkill (int pid, struct remote_state *rs);
+static void remote_kill_k (void);
+
static void remote_mourn (struct target_ops *ops);
static void extended_remote_restart (void);
-static void extended_remote_mourn (struct target_ops *);
-
static void remote_send (char **buf, long *sizeof_buf_p);
static int readchar (int timeout);
@@ -1918,7 +1918,8 @@ demand_private_info (ptid_t ptid)
info->priv = XNEW (struct private_thread_info);
info->private_dtor = free_private_thread_info;
info->priv->core = -1;
- info->priv->extra = 0;
+ info->priv->extra = NULL;
+ info->priv->name = NULL;
}
return info->priv;
@@ -2097,7 +2098,7 @@ set_general_process (void)
struct remote_state *rs = get_remote_state ();
/* If the remote can't handle multiple processes, don't bother. */
- if (!rs->extended || !remote_multi_process_p (rs))
+ if (!remote_multi_process_p (rs))
return;
/* We only need to change the remote current thread if it's pointing
@@ -4609,18 +4610,15 @@ remote_query_supported (void)
q = remote_query_supported_append (q, "qRelocInsn+");
- if (rs->extended)
- {
- if (packet_set_cmd_state (PACKET_fork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "fork-events+");
- if (packet_set_cmd_state (PACKET_vfork_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "vfork-events+");
- if (packet_set_cmd_state (PACKET_exec_event_feature)
- != AUTO_BOOLEAN_FALSE)
- q = remote_query_supported_append (q, "exec-events+");
- }
+ if (packet_set_cmd_state (PACKET_fork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "fork-events+");
+ if (packet_set_cmd_state (PACKET_vfork_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "vfork-events+");
+ if (packet_set_cmd_state (PACKET_exec_event_feature)
+ != AUTO_BOOLEAN_FALSE)
+ q = remote_query_supported_append (q, "exec-events+");
if (packet_set_cmd_state (PACKET_vContSupported) !=
AUTO_BOOLEAN_FALSE)
q = remote_query_supported_append (q, "vContSupported+");
@@ -4975,7 +4973,8 @@ remote_detach_1 (const char *args, int from_tty)
/* Tell the remote target to detach. */
remote_detach_pid (pid);
- if (from_tty && !rs->extended)
+ /* Exit only if this is the only active inferior. */
+ if (from_tty && !rs->extended && number_of_live_inferiors () == 1)
puts_filtered (_("Ending remote debugging.\n"));
/* Check to see if we are detaching a fork parent. Note that if we
@@ -5071,10 +5070,11 @@ remote_disconnect (struct target_ops *target,
const char *args, int from_tty)
if (args)
error (_("Argument given to \"disconnect\" when remotely debugging."));
- /* Make sure we unpush even the extended remote targets; mourn
- won't do it. So call remote_mourn directly instead of
- target_mourn_inferior. */
- remote_mourn (target);
+ /* Make sure we unpush even the extended remote targets. Calling
+ target_mourn_inferior won't unpush, and remote_mourn won't
+ unpush if there is more than one inferior left. */
+ unpush_target (target);
+ generic_mourn_inferior ();
if (from_tty)
puts_filtered ("Ending remote debugging.\n");
@@ -8800,42 +8800,53 @@ kill_new_fork_children (int pid, struct
remote_state *rs)
}
\f
+/* Target hook to kill the current inferior. */
+
static void
remote_kill (struct target_ops *ops)
{
+ int res = -1;
+ int pid = ptid_get_pid (inferior_ptid);
+ struct remote_state *rs = get_remote_state ();
- /* Catch errors so the user can quit from gdb even when we
- aren't on speaking terms with the remote system. */
- TRY
+ if (packet_support (PACKET_vKill) != PACKET_DISABLE)
{
- putpkt ("k");
- }
- CATCH (ex, RETURN_MASK_ERROR)
- {
- if (ex.error == TARGET_CLOSE_ERROR)
+ /* If we're stopped while forking and we haven't followed yet,
+ kill the child task. We need to do this before killing the
+ parent task because if this is a vfork then the parent will
+ be sleeping. */
+ kill_new_fork_children (pid, rs);
+
+ res = remote_vkill (pid, rs);
+ if (res == 0)
{
- /* If we got an (EOF) error that caused the target
- to go away, then we're done, that's what we wanted.
- "k" is susceptible to cause a premature EOF, given
- that the remote server isn't actually required to
- reply to "k", and it can happen that it doesn't
- even get to reply ACK to the "k". */
+ target_mourn_inferior ();
return;
}
+ }
- /* Otherwise, something went wrong. We didn't actually kill
- the target. Just propagate the exception, and let the
- user or higher layers decide what to do. */
- throw_exception (ex);
+ /* If we are in 'target remote' mode and we are killing the only
+ inferior, then we will tell gdbserver to exit and unpush the
+ target. */
+ if (res == -1 && !remote_multi_process_p (rs)
+ && number_of_live_inferiors () == 1)
+ {
+ remote_kill_k ();
+
+ /* We've killed the remote end, we get to mourn it. If we are
+ not in extended mode, mourning the inferior also unpushes
+ remote_ops from the target stack, which closes the remote
+ connection. */
+ target_mourn_inferior ();
+
+ return;
}
- END_CATCH
- /* We've killed the remote end, we get to mourn it. Since this is
- target remote, single-process, mourning the inferior also
- unpushes remote_ops. */
- target_mourn_inferior ();
+ error (_("Can't kill process"));
}
+/* Send a kill request to the target using the 'vKill' packet. */
+
static int
remote_vkill (int pid, struct remote_state *rs)
{
@@ -8861,55 +8872,52 @@ remote_vkill (int pid, struct remote_state *rs)
}
}
+/* Send a kill request to the target using the 'k' packet. */
+
static void
-extended_remote_kill (struct target_ops *ops)
+remote_kill_k (void)
{
- int res;
- int pid = ptid_get_pid (inferior_ptid);
- struct remote_state *rs = get_remote_state ();
-
- /* If we're stopped while forking and we haven't followed yet, kill the
- child task. We need to do this before killing the parent task
- because if this is a vfork then the parent will be sleeping. */
- kill_new_fork_children (pid, rs);
-
- res = remote_vkill (pid, rs);
- if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
+ /* Catch errors so the user can quit from gdb even when we
+ aren't on speaking terms with the remote system. */
+ TRY
{
- /* Don't try 'k' on a multi-process aware stub -- it has no way
- to specify the pid. */
-
putpkt ("k");
-#if 0
- getpkt (&rs->buf, &rs->buf_size, 0);
- if (rs->buf[0] != 'O' || rs->buf[0] != 'K')
- res = 1;
-#else
- /* Don't wait for it to die. I'm not really sure it matters whether
- we do or not. For the existing stubs, kill is a noop. */
- res = 0;
-#endif
}
+ CATCH (ex, RETURN_MASK_ERROR)
+ {
+ if (ex.error == TARGET_CLOSE_ERROR)
+ {
+ /* If we got an (EOF) error that caused the target
+ to go away, then we're done, that's what we wanted.
+ "k" is susceptible to cause a premature EOF, given
+ that the remote server isn't actually required to
+ reply to "k", and it can happen that it doesn't
+ even get to reply ACK to the "k". */
+ return;
+ }
- if (res != 0)
- error (_("Can't kill process"));
-
- target_mourn_inferior ();
+ /* Otherwise, something went wrong. We didn't actually kill
+ the target. Just propagate the exception, and let the
+ user or higher layers decide what to do. */
+ throw_exception (ex);
+ }
+ END_CATCH
}
static void
remote_mourn (struct target_ops *target)
{
- unpush_target (target);
+ struct remote_state *rs = get_remote_state ();
- /* remote_close takes care of doing most of the clean up. */
- generic_mourn_inferior ();
-}
+ /* In 'target remote' mode with one inferior, we close the
connection. */
+ if (!rs->extended && number_of_live_inferiors () <= 1)
+ {
+ unpush_target (target);
-static void
-extended_remote_mourn (struct target_ops *target)
-{
- struct remote_state *rs = get_remote_state ();
+ /* remote_close takes care of doing most of the clean up. */
+ generic_mourn_inferior ();
+ return;
+ }
/* In case we got here due to an error, but we're going to stay
connected. */
@@ -8940,10 +8948,7 @@ extended_remote_mourn (struct target_ops *target)
current thread. */
record_currthread (rs, minus_one_ptid);
- /* Unlike "target remote", we do not want to unpush the target; then
- the next time the user says "run", we won't be connected. */
-
- /* Call common code to mark the inferior as not running. */
+ /* Call common code to mark the inferior as not running. */
generic_mourn_inferior ();
if (!have_inferiors ())
@@ -10465,7 +10470,7 @@ remote_pid_to_str (struct target_ops *ops,
ptid_t ptid)
{
if (ptid_equal (magic_null_ptid, ptid))
xsnprintf (buf, sizeof buf, "Thread <main>");
- else if (rs->extended && remote_multi_process_p (rs))
+ else if (remote_multi_process_p (rs))
if (ptid_get_lwp (ptid) == 0)
return normal_pid_to_str (ptid);
else
@@ -11635,11 +11640,7 @@ remote_supports_multi_process (struct
target_ops *self)
{
struct remote_state *rs = get_remote_state ();
- /* Only extended-remote handles being attached to multiple
- processes, even though plain remote can use the multi-process
- thread id extensions, so that GDB knows the target process's
- PID. */
- return rs->extended && remote_multi_process_p (rs);
+ return remote_multi_process_p (rs);
}
static int
@@ -13071,6 +13072,14 @@ Specify the serial device it is connected to\n\
remote_ops.to_btrace_conf = remote_btrace_conf;
remote_ops.to_augmented_libraries_svr4_read =
remote_augmented_libraries_svr4_read;
+ remote_ops.to_follow_fork = remote_follow_fork;
+ remote_ops.to_follow_exec = remote_follow_exec;
+ remote_ops.to_insert_fork_catchpoint = remote_insert_fork_catchpoint;
+ remote_ops.to_remove_fork_catchpoint = remote_remove_fork_catchpoint;
+ remote_ops.to_insert_vfork_catchpoint = remote_insert_vfork_catchpoint;
+ remote_ops.to_remove_vfork_catchpoint = remote_remove_vfork_catchpoint;
+ remote_ops.to_insert_exec_catchpoint = remote_insert_exec_catchpoint;
+ remote_ops.to_remove_exec_catchpoint = remote_remove_exec_catchpoint;
}
/* Set up the extended remote vector by making a copy of the standard
@@ -13089,27 +13098,11 @@ init_extended_remote_ops (void)
Specify the serial device it is connected to (e.g. /dev/ttya).";
extended_remote_ops.to_open = extended_remote_open;
extended_remote_ops.to_create_inferior = extended_remote_create_inferior;
- extended_remote_ops.to_mourn_inferior = extended_remote_mourn;
extended_remote_ops.to_detach = extended_remote_detach;
extended_remote_ops.to_attach = extended_remote_attach;
extended_remote_ops.to_post_attach = extended_remote_post_attach;
- extended_remote_ops.to_kill = extended_remote_kill;
extended_remote_ops.to_supports_disable_randomization
= extended_remote_supports_disable_randomization;
- extended_remote_ops.to_follow_fork = remote_follow_fork;
- extended_remote_ops.to_follow_exec = remote_follow_exec;
- extended_remote_ops.to_insert_fork_catchpoint
- = remote_insert_fork_catchpoint;
- extended_remote_ops.to_remove_fork_catchpoint
- = remote_remove_fork_catchpoint;
- extended_remote_ops.to_insert_vfork_catchpoint
- = remote_insert_vfork_catchpoint;
- extended_remote_ops.to_remove_vfork_catchpoint
- = remote_remove_vfork_catchpoint;
- extended_remote_ops.to_insert_exec_catchpoint
- = remote_insert_exec_catchpoint;
- extended_remote_ops.to_remove_exec_catchpoint
- = remote_remove_exec_catchpoint;
}
static int
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* [pushed] Re: [PATCH v2 3/3] Target remote mode fork and exec docs
2015-12-08 13:07 ` Pedro Alves
@ 2015-12-14 19:30 ` Don Breazeal
0 siblings, 0 replies; 24+ messages in thread
From: Don Breazeal @ 2015-12-14 19:30 UTC (permalink / raw)
To: Pedro Alves, Eli Zaretskii, gdb-patches
On 12/8/2015 5:07 AM, Pedro Alves wrote:
> On 12/07/2015 10:14 PM, Don Breazeal wrote:
>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index a222dfb..bec9810 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -127,6 +127,15 @@ show remote exec-event-feature-packet
>> The reply to qXfer:threads:read may now include a name attribute for each
>> thread.
>>
>> +* Target remote mode fork and exec events
>> +
>> + ** GDB now has support for fork and exec events on target remote mode
>> + Linux targets. For such targets with Linux kernels 2.5.46 and later,
>> + this enables follow-fork-mode, detach-on-fork, follow-exec-mode, and
>> + fork and exec catchpoints. Note that follow-exec-mode is of limited
>> + usefulness, because target remote mode does not support the 'run'
>> + command.
>
> ...
>
>>
>> +@code{follow-exec-mode} is supported in native mode and
>> +@code{target extended-remote} mode. It is of limited usefulness in
>> +@code{target remote} mode since the run command is not supported in that
>> +mode.
>
> Thinking about this some more, I'm really not sure we should be calling out
> this limited usefulness here (and NEWS). It seems just as useful in
> remote mode -- it's just that when you want to restart the debugging from
> the starting binary, you do "target remote" again instead of "run" then.
This comment has been removed everywhere.
>
> Thanks,
> Pedro Alves
>
This is now pushed.
Thanks
--Don
From: Don Breazeal <donb@codesourcery.com>
Subject: [pushed][PATCH v3 3/3] Target remote mode fork and exec docs
This is the version of the patch that was pushed. The only differences
between this version and v2 are that any comments about the usefulness
of follow-exec-mode in target remote mode have been removed.
Here is the commit message:
This patch implements documentation updates for target remote mode fork and
exec events. A summary of the rationale for the changes made here:
* Connecting to a remote target -- explain that the two protocols exist.
* Connecting in target remote mode -- explain invoking gdbserver for target
remote mode, and move remote-specific text from original "Connecting to a
remote target" section.
* Connecting in target extended-remote mode -- promote this section from
"Using the gdbserver Program | Running gdbserver | Multi-Process Mode for
gdbserver". Put it next to the target remote mode section.
* Host and target files -- collect paragraphs dealing with how to locate
symbol files from original sections "Connecting to a remote target" and
"Using the gdbserver program | Connecting to gdbserver".
* Steps for connecting to a remote target -- used to be "Using the
gdbserver program | Connecting to gdbserver"
* Remote connection commands -- used to be the bulk of "Connecting to a
remote target". Added "target extended-remote" commands and information.
gdb/ChangeLog:
* NEWS: Announce fork and exec event support for target remote.
gdb/doc/ChangeLog:
* gdb.texinfo (Forks): Correct Linux kernel version where
fork and exec events are supported, add notes about support
of these events in target remote mode.
(Connecting): Reorganize and clarify distinctions between
target remote, extended-remote, and multiprocess.
Reorganize related text from separate sections into new
sections.
(Server): Note effects of target extended-remote mode.
Delete section on Multi-Process Mode for gdbserver.
Move some text to "Connecting" node.
---
gdb/ChangeLog | 4 +
gdb/NEWS | 7 ++
gdb/doc/ChangeLog | 13 +++
gdb/doc/gdb.texinfo | 266
+++++++++++++++++++++++++++++++++++++---------------
4 files changed, 213 insertions(+), 77 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 9ded377..5eece01 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,9 @@
2015-12-11 Don Breazeal <donb@codesourcery.com>
+ * NEWS: Announce fork and exec event support for target remote.
+
+2015-12-11 Don Breazeal <donb@codesourcery.com>
+
* inferior.c (number_of_live_inferiors): New function.
(have_live_inferiors): Use number_of_live_inferiors in place
of duplicate code.
diff --git a/gdb/NEWS b/gdb/NEWS
index 9ca7f49..484d98d 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -135,6 +135,13 @@ show remote exec-event-feature-packet
The reply to qXfer:threads:read may now include a name attribute for
each
thread.
+* Target remote mode fork and exec events
+
+ ** GDB now has support for fork and exec events on target remote mode
+ Linux targets. For such targets with Linux kernels 2.5.46 and later,
+ this enables follow-fork-mode, detach-on-fork, follow-exec-mode, and
+ fork and exec catchpoints.
+
* MI changes
** The -var-set-format command now accepts the zero-hexadecimal
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index fc81d09..ef3bdaa 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,16 @@
+2015-12-11 Don Breazeal <donb@codesourcery.com>
+
+ * gdb.texinfo (Forks): Correct Linux kernel version where
+ fork and exec events are supported, add notes about support
+ of these events in target remote mode.
+ (Connecting): Reorganize and clarify distinctions between
+ target remote, extended-remote, and multiprocess.
+ Reorganize related text from separate sections into new
+ sections.
+ (Server): Note effects of target extended-remote mode.
+ Delete section on Multi-Process Mode for gdbserver.
+ Move some text to "Connecting" node.
+
2015-12-10 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Replace warning with explanation
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index bb68e21..7cc1b35 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -3119,10 +3119,11 @@ the child process just like any other process
which you attached to.
On some systems, @value{GDBN} provides support for debugging programs
that create additional processes using the @code{fork} or @code{vfork}
functions. On @sc{gnu}/Linux platforms, this feature is supported
-with kernel version 2.5.60 and later.
+with kernel version 2.5.46 and later.
-The fork debugging commands are supported in both native mode and when
-connected to @code{gdbserver} using @kbd{target extended-remote}.
+The fork debugging commands are supported in native mode and when
+connected to @code{gdbserver} in either @code{target remote} mode or
+@code{target extended-remote} mode.
By default, when a program forks, @value{GDBN} will continue to debug
the parent process and the child process will run unimpeded.
@@ -3268,6 +3269,9 @@ Program exited normally.
@end table
@end table
+@code{follow-exec-mode} is supported in native mode and
+@code{target extended-remote} mode.
+
You can use the @code{catch} command to make @value{GDBN} stop whenever
a @code{fork}, @code{vfork}, or @code{exec} call is made. @xref{Set
Catchpoints, ,Setting Catchpoints}.
@@ -19248,28 +19252,148 @@ configuration of @value{GDBN}; use @code{help
target} to list them.
@node Connecting
@section Connecting to a Remote Target
+@cindex remote debugging, connecting
+@cindex @code{gdbserver}, connecting
+@cindex remote debugging, types of connections
+@cindex @code{gdbserver}, types of connections
+@cindex @code{gdbserver}, @code{target remote} mode
+@cindex @code{gdbserver}, @code{target extended-remote} mode
+
+This section describes how to connect to a remote target, including the
+types of connections and their differences, how to set up executable and
+symbol files on the host and target, and the commands used for
+connecting to and disconnecting from the remote target.
+
+@subsection Types of Remote Connections
+
+@value{GDBN} supports two types of remote connections, @code{target remote}
+mode and @code{target extended-remote} mode. Note that many remote targets
+support only @code{target remote} mode. There are several major
+differences between the two types of connections, enumerated here:
-@value{GDBN} needs an unstripped copy of your program to access symbol
-and debugging information. Some remote targets (@pxref{qXfer
-executable filename read}, and @pxref{Host I/O Packets}) allow
-@value{GDBN} to access program files over the same connection used to
-communicate with @value{GDBN}. With such a target, if the remote
-program is unstripped, the only command you need is @code{target
-remote}. Otherwise, start up @value{GDBN} using the name of the local
+@table @asis
+
+@cindex remote debugging, detach and program exit
+@item Result of detach or program exit
+@strong{With target remote mode:} When the debugged program exits or you
+detach from it, @value{GDBN} disconnects from the target. When using
+@code{gdbserver}, @code{gdbserver} will exit.
+
+@strong{With target extended-remote mode:} When the debugged program
exits or
+you detach from it, @value{GDBN} remains connected to the target, even
+though no program is running. You can rerun the program, attach to a
+running program, or use @code{monitor} commands specific to the target.
+
+When using @code{gdbserver} in this case, it does not exit unless it was
+invoked using the @option{--once} option. If the @option{--once} option
+was not used, you can ask @code{gdbserver} to exit using the
+@code{monitor exit} command (@pxref{Monitor Commands for gdbserver}).
+
+@item Specifying the program to debug
+For both connection types you use the @code{file} command to specify the
+program on the host system. If you are using @code{gdbserver} there are
+some differences in how to specify the location of the program on the
+target.
+
+@strong{With target remote mode:} You must either specify the program
to debug
+on the @code{gdbserver} command line or use the @option{--attach} option
+(@pxref{Attaching to a program,,Attaching to a Running Program}).
+
+@cindex @option{--multi}, @code{gdbserver} option
+@strong{With target extended-remote mode:} You may specify the program
to debug
+on the @code{gdbserver} command line, or you can load the program or attach
+to it using @value{GDBN} commands after connecting to @code{gdbserver}.
+
+@anchor{--multi Option in Types of Remote Connnections}
+You can start @code{gdbserver} without supplying an initial command to run
+or process ID to attach. To do this, use the @option{--multi} command line
+option. Then you can connect using @code{target extended-remote} and start
+the program you want to debug (see below for details on using the
+@code{run} command in this scenario). Note that the conditions under which
+@code{gdbserver} terminates depend on how @value{GDBN} connects to it
+(@code{target remote} or @code{target extended-remote}). The
+@option{--multi} option to @code{gdbserver} has no influence on that.
+
+@item The @code{run} command
+@strong{With target remote mode:} The @code{run} command is not
+supported. Once a connection has been established, you can use all
+the usual @value{GDBN} commands to examine and change data. The
+remote program is already running, so you can use commands like
+@kbd{step} and @kbd{continue}.
+
+@strong{With target extended-remote mode:} The @code{run} command is
+supported. The @code{run} command uses the value set by
+@code{set remote exec-file} (@pxref{set remote exec-file}) to select
+the program to run. Command line arguments are supported, except for
+wildcard expansion and I/O redirection (@pxref{Arguments}).
+
+If you specify the program to debug on the command line, then the
+@code{run} command is not required to start execution, and you can
+resume using commands like @kbd{step} and @kbd{continue} as with
+@code{target remote} mode.
+
+@anchor{Attaching in Types of Remote Connections}
+@item Attaching
+@strong{With target remote mode:} The @value{GDBN} command @code{attach} is
+not supported. To attach to a running program using @code{gdbserver}, you
+must use the @option{--attach} option (@pxref{Running gdbserver}).
+
+@strong{With target extended-remote mode:} To attach to a running program,
+you may use the @code{attach} command after the connection has been
+established. If you are using @code{gdbserver}, you may also invoke
+@code{gdbserver} using the @option{--attach} option
+(@pxref{Running gdbserver}).
+
+@end table
+
+@anchor{Host and target files}
+@subsection Host and Target Files
+@cindex remote debugging, symbol files
+@cindex symbol files, remote debugging
+
+@value{GDBN}, running on the host, needs access to symbol and debugging
+information for your program running on the target. This requires
+access to an unstripped copy of your program, and possibly any associated
+symbol files. Note that this section applies equally to both @code{target
+remote} mode and @code{target extended-remote} mode.
+
+Some remote targets (@pxref{qXfer executable filename read}, and
+@pxref{Host I/O Packets}) allow @value{GDBN} to access program files over
+the same connection used to communicate with @value{GDBN}. With such a
+target, if the remote program is unstripped, the only command you need is
+@code{target remote} (or @code{target extended-remote}).
+
+If the remote program is stripped, or the target does not support remote
+program file access, start up @value{GDBN} using the name of the local
unstripped copy of your program as the first argument, or use the
-@code{file} command.
+@code{file} command. Use @code{set sysroot} to specify the location (on
+the host) of target libraries (unless your @value{GDBN} was compiled with
+the correct sysroot using @code{--with-sysroot}). Alternatively, you
+may use @code{set solib-search-path} to specify how @value{GDBN} locates
+target libraries.
+
+The symbol file and target libraries must exactly match the executable
+and libraries on the target, with one exception: the files on the host
+system should not be stripped, even if the files on the target system
+are. Mismatched or missing files will lead to confusing results
+during debugging. On @sc{gnu}/Linux targets, mismatched or missing
+files may also prevent @code{gdbserver} from debugging multi-threaded
+programs.
-@cindex @code{target remote}
+@subsection Remote Connection Commands
+@cindex remote connection commands
@value{GDBN} can communicate with the target over a serial line, or
over an @acronym{IP} network using @acronym{TCP} or @acronym{UDP}. In
each case, @value{GDBN} uses the same protocol for debugging your
program; only the medium carrying the debugging packets varies. The
-@code{target remote} command establishes a connection to the target.
-Its arguments indicate which medium to use:
+@code{target remote} and @code{target extended-remote} commands
+establish a connection to the target. Both commands accept the same
+arguments, which indicate the medium to use:
@table @code
@item target remote @var{serial-device}
+@itemx target extended-remote @var{serial-device}
@cindex serial line, @code{target remote}
Use @var{serial-device} to communicate with the target. For example,
to use a serial line connected to the device named @file{/dev/ttyb}:
@@ -19285,6 +19409,8 @@ If you're using a serial line, you may want to
give @value{GDBN} the
@item target remote @code{@var{host}:@var{port}}
@itemx target remote @code{tcp:@var{host}:@var{port}}
+@itemx target extended-remote @code{@var{host}:@var{port}}
+@itemx target extended-remote @code{tcp:@var{host}:@var{port}}
@cindex @acronym{TCP} port, @code{target remote}
Debug using a @acronym{TCP} connection to @var{port} on @var{host}.
The @var{host} may be either a host name or a numeric @acronym{IP}
@@ -19313,6 +19439,7 @@ target remote :1234
Note that the colon is still required here.
@item target remote @code{udp:@var{host}:@var{port}}
+@itemx target extended-remote @code{udp:@var{host}:@var{port}}
@cindex @acronym{UDP} port, @code{target remote}
Debug using @acronym{UDP} packets to @var{port} on @var{host}. For
example, to
connect to @acronym{UDP} port 2828 on a terminal server named
@code{manyfarms}:
@@ -19327,6 +19454,7 @@ can silently drop packets on busy or unreliable
networks, which will
cause havoc with your debugging session.
@item target remote | @var{command}
+@itemx target extended-remote | @var{command}
@cindex pipe, @code{target remote} to
Run @var{command} in the background and communicate with it using a
pipe. The @var{command} is a shell command, to be parsed and expanded
@@ -19342,11 +19470,6 @@ program has already exited, this will have no
effect.)
@end table
-Once the connection has been established, you can use all the usual
-commands to examine and change data. The remote program is already
-running; you can use @kbd{step} and @kbd{continue}, and you do not
-need to use @kbd{run}.
-
@cindex interrupting remote programs
@cindex remote programs, interrupting
Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -19360,10 +19483,13 @@ Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n)
@end smallexample
-If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
-remote} again to connect once more.) If you type @kbd{n}, @value{GDBN}
-goes back to waiting.
+In @code{target remote} mode, if you type @kbd{y}, @value{GDBN} abandons
+the remote debugging session. (If you decide you want to try again later,
+you can use @kbd{target remote} again to connect once more.) If you type
+@kbd{n}, @value{GDBN} goes back to waiting.
+
+In @code{target extended-remote} mode, typing @kbd{n} will leave
+@value{GDBN} connected to the target.
@table @code
@kindex detach (remote)
@@ -19372,11 +19498,13 @@ When you have finished debugging the remote
program, you can use the
@code{detach} command to release it from @value{GDBN} control.
Detaching from the target normally resumes its execution, but the results
will depend on your particular remote stub. After the @code{detach}
-command, @value{GDBN} is free to connect to another target.
+command in @code{target remote} mode, @value{GDBN} is free to connect to
+another target. In @code{target extended-remote} mode, @value{GDBN} is
+still connected to the target.
@kindex disconnect
@item disconnect
-The @code{disconnect} command behaves like @code{detach}, except that
+The @code{disconnect} command closes the connection to the target, and
the target is generally not resumed. It will wait for @value{GDBN}
(this instance or another one) to connect and continue debugging. After
the @code{disconnect} command, @value{GDBN} is again free to connect to
@@ -19433,7 +19561,8 @@ Delete @var{targetfile} from the target system.
@cindex remote connection without stubs
@code{gdbserver} is a control program for Unix-like systems, which
allows you to connect your program with a remote @value{GDBN} via
-@code{target remote}---but without linking in the usual debugging stub.
+@code{target remote} or @code{target extended-remote}---but without
+linking in the usual debugging stub.
@code{gdbserver} is not a complete replacement for the debugging stubs,
because it requires essentially the same operating-system facilities
@@ -19461,6 +19590,7 @@ target system with the same privileges as the
user running
@code{gdbserver}.
@end quotation
+@anchor{Running gdbserver}
@subsection Running @code{gdbserver}
@cindex arguments, to @code{gdbserver}
@cindex @code{gdbserver}, command-line arguments
@@ -19528,6 +19658,7 @@ Programs started with stdio-connected gdbserver
have @file{/dev/null} for
display through a pipe connected to gdbserver.
Both @code{stdout} and @code{stderr} use the same pipe.
+@anchor{Attaching to a program}
@subsubsection Attaching to a Running Program
@cindex attach to a program, @code{gdbserver}
@cindex @option{--attach}, @code{gdbserver} option
@@ -19539,8 +19670,12 @@ This is accomplished via the @code{--attach}
argument. The syntax is:
target> gdbserver --attach @var{comm} @var{pid}
@end smallexample
-@var{pid} is the process ID of a currently running process. It isn't
necessary
-to point @code{gdbserver} at a binary for the running process.
+@var{pid} is the process ID of a currently running process. It isn't
+necessary to point @code{gdbserver} at a binary for the running process.
+
+In @code{target extended-remote} mode, you can also attach using the
+@value{GDBN} attach command
+(@pxref{Attaching in Types of Remote Connections}).
@pindex pidof
You can debug processes by name instead of process ID if your target
has the
@@ -19554,41 +19689,10 @@ In case more than one copy of @var{program} is
running, or @var{program}
has multiple threads, most versions of @code{pidof} support the
@code{-s} option to only return the first process ID.
-@subsubsection Multi-Process Mode for @code{gdbserver}
-@cindex @code{gdbserver}, multiple processes
-@cindex multiple processes with @code{gdbserver}
-
-When you connect to @code{gdbserver} using @code{target remote},
-@code{gdbserver} debugs the specified program only once. When the
-program exits, or you detach from it, @value{GDBN} closes the connection
-and @code{gdbserver} exits.
-
-If you connect using @kbd{target extended-remote}, @code{gdbserver}
-enters multi-process mode. When the debugged program exits, or you
-detach from it, @value{GDBN} stays connected to @code{gdbserver} even
-though no program is running. The @code{run} and @code{attach}
-commands instruct @code{gdbserver} to run or attach to a new program.
-The @code{run} command uses @code{set remote exec-file} (@pxref{set
-remote exec-file}) to select the program to run. Command line
-arguments are supported, except for wildcard expansion and I/O
-redirection (@pxref{Arguments}).
-
-@cindex @option{--multi}, @code{gdbserver} option
-To start @code{gdbserver} without supplying an initial command to run
-or process ID to attach, use the @option{--multi} command line option.
-Then you can connect using @kbd{target extended-remote} and start
-the program you want to debug.
-
-In multi-process mode @code{gdbserver} does not automatically exit
unless you
-use the option @option{--once}. You can terminate it by using
-@code{monitor exit} (@pxref{Monitor Commands for gdbserver}). Note
that the
-conditions under which @code{gdbserver} terminates depend on how
@value{GDBN}
-connects to it (@kbd{target remote} or @kbd{target extended-remote}). The
-@option{--multi} option to @code{gdbserver} has no influence on that.
-
@subsubsection TCP port allocation lifecycle of @code{gdbserver}
-This section applies only when @code{gdbserver} is run to listen on a
TCP port.
+This section applies only when @code{gdbserver} is run to listen on a TCP
+port.
@code{gdbserver} normally terminates after all of its debugged
processes have
terminated in @kbd{target remote} mode. On the other hand, for @kbd{target
@@ -19619,6 +19723,12 @@ instance closes its port after the first
connection.
@anchor{Other Command-Line Arguments for gdbserver}
@subsubsection Other Command-Line Arguments for @code{gdbserver}
+You can use the @option{--multi} option to start @code{gdbserver} without
+specifying a program to debug or a process to attach to. Then you can
+attach in @code{target extended-remote} mode and run or attach to a
+program. For more information,
+@pxref{--multi Option in Types of Remote Connnections}.
+
@cindex @option{--debug}, @code{gdbserver} option
The @option{--debug} option tells @code{gdbserver} to display extra
status information about the debugging process.
@@ -19670,32 +19780,34 @@ $ gdbserver --wrapper env
LD_PRELOAD=libtest.so -- :2222 ./testprog
@subsection Connecting to @code{gdbserver}
-Run @value{GDBN} on the host system.
+The basic procedure for connecting to the remote target is:
+@itemize
-First make sure you have the necessary symbol files. Load symbols for
-your application using the @code{file} command before you connect. Use
-@code{set sysroot} to locate target libraries (unless your @value{GDBN}
-was compiled with the correct sysroot using @code{--with-sysroot}).
+@item
+Run @value{GDBN} on the host system.
-The symbol file and target libraries must exactly match the executable
-and libraries on the target, with one exception: the files on the host
-system should not be stripped, even if the files on the target system
-are. Mismatched or missing files will lead to confusing results
-during debugging. On @sc{gnu}/Linux targets, mismatched or missing
-files may also prevent @code{gdbserver} from debugging multi-threaded
-programs.
+@item
+Make sure you have the necessary symbol files
+(@pxref{Host and target files}).
+Load symbols for your application using the @code{file} command before you
+connect. Use @code{set sysroot} to locate target libraries (unless your
+@value{GDBN} was compiled with the correct sysroot using
+@code{--with-sysroot}).
+@item
Connect to your target (@pxref{Connecting,,Connecting to a Remote Target}).
For TCP connections, you must start up @code{gdbserver} prior to using
-the @code{target remote} command. Otherwise you may get an error whose
+the @code{target} command. Otherwise you may get an error whose
text depends on the host system, but which usually looks something like
@samp{Connection refused}. Don't use the @code{load}
-command in @value{GDBN} when using @code{gdbserver}, since the program is
-already on the target.
+command in @value{GDBN} when using @code{target remote} mode, since the
+program is already on the target.
+
+@end itemize
+@anchor{Monitor Commands for gdbserver}
@subsection Monitor Commands for @code{gdbserver}
@cindex monitor commands, for @code{gdbserver}
-@anchor{Monitor Commands for gdbserver}
During a @value{GDBN} session using @code{gdbserver}, you can use the
@code{monitor} command to send special requests to @code{gdbserver}.
--
1.8.1.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v2 2/3] Target remote mode fork and exec events
2015-12-14 19:29 ` Don Breazeal
@ 2015-12-15 10:52 ` Pedro Alves
0 siblings, 0 replies; 24+ messages in thread
From: Pedro Alves @ 2015-12-15 10:52 UTC (permalink / raw)
To: Don Breazeal, gdb-patches
On 12/14/2015 07:29 PM, Don Breazeal wrote:
> On 12/8/2015 4:55 AM, Pedro Alves wrote:
> Wow. I have a backlog of new tests that we've talked about related to
> the fork/exec event support. I can likely make some other tests out of
> the above as well.
That'd be great, thanks!
>>
>> Sorry, I'm confused. Does this series cause a new FAIL, or not?
>
> Sorry about the gibberish. It is a FAIL that didn't occur with target
> remote mode before, but now it behaves identically to how native and
> extended-remote behave by generating the FAIL.
Ah, I see now. Sorry for being dense.
>
> This is now pushed; the updated patch is attached.
> I think with this, basic remote fork and exec events are complete. I
> appreciate all your help with this project, Pedro. Thanks for hanging
> in there with me!
Thanks for doing all this!
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-12-15 10:52 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-06 23:56 [PATCH 0/3] Target remote mode fork and exec support Don Breazeal
2015-11-06 23:57 ` [PATCH 1/3] Target remote mode fork and exec events Don Breazeal
2015-11-20 13:04 ` Pedro Alves
2015-11-20 16:50 ` Don Breazeal
2015-12-07 22:14 ` [PATCH v2 0/3] Target remote mode fork and exec support Don Breazeal
2015-12-07 22:14 ` [PATCH v2 2/3] Target remote mode fork and exec events Don Breazeal
2015-12-08 12:55 ` Pedro Alves
2015-12-14 19:29 ` Don Breazeal
2015-12-15 10:52 ` Pedro Alves
2015-12-07 22:14 ` [PATCH v2 1/3] Target remote mode fork and exec tests Don Breazeal
2015-12-08 12:58 ` Pedro Alves
2015-12-14 19:29 ` [pushed] " Don Breazeal
2015-12-07 22:15 ` [PATCH v2 3/3] Target remote mode fork and exec docs Don Breazeal
2015-12-08 13:07 ` Pedro Alves
2015-12-14 19:30 ` [pushed] " Don Breazeal
2015-12-08 13:11 ` [PATCH v2 0/3] Target remote mode fork and exec support Pedro Alves
2015-11-06 23:57 ` [PATCH 2/3] Target remote mode fork and exec tests Don Breazeal
2015-11-06 23:57 ` [PATCH 3/3] Target remote mode fork and exec docs Don Breazeal
2015-11-07 8:18 ` Eli Zaretskii
2015-11-12 1:00 ` Don Breazeal
2015-11-12 1:00 ` Don Breazeal
2015-11-12 16:48 ` Eli Zaretskii
2015-11-13 1:13 ` Don Breazeal
2015-11-13 8:16 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).