2d717e4f8a
(linux_kill, linux_detach): Clean up the process list. * remote-utils.c (remote_open): Improve port number parsing. (putpkt_binary, input_interrupt): Only send interrupts if the target is running. * server.c (extended_protocol): Make static. (attached): Define earlier. (exit_requested, response_needed, program_argv): New variables. (target_running): New. (start_inferior): Clear attached here. (attach_inferior): Set attached here. (require_running): Define. (handle_query): Use require_running and target_running. Implement "monitor exit". (handle_v_attach, handle_v_run): New. (handle_v_requests): Use require_running. Handle vAttach and vRun. (gdbserver_usage): Update. (main): Redo argument parsing. Handle --debug and --multi. Handle --attach along with other options or after the port. Save program_argv. Support no initial program. Resynchronize communication with GDB after an error. Handle "monitor exit". Use require_running and target_running. Always allow the extended protocol. Do not error out for Hc0 or Hc-1. Do not automatically restart in extended mode. * README: Refer to the GDB manual. Update --attach usage. * remote.c (struct remote_state): Add cached_wait_status. (remote_exec_file): New variable. (PACKET_vAttach, PACKET_vRun): New constants. (extended_remote_restart): Do not query for status. (struct start_remote_args): New. (remote_start_remote): Take it as a second argument. Check whether the target is running. Issue an error for non-running non-extended targets. Cache the wait status. Set inferior_ptid here. (remote_open_1): Prompt to disconnect non-running targets. Make sure the target is marked running. Do not set inferior_ptid here. Update call to remote_start_remote. Do not call remote_check_symbols if the target is not running. (remote_detach_1): Rename from remote_detach. Take an EXTENDED argument. Handle a non-running target. (remote_detach): Use it. (extended_remote_detach): New. (remote_disconnect): Fix typo. Use remoute_mourn_1. (extended_remote_attach_1, extended_remote_attach) (extended_async_remote_attach): New. (remote_vcont_resume): Remove unused variable. (remote_wait, remote_async_wait): Use any cached wait status. (putpkt_binary, getpkt): Clear any cached wait status. (extended_remoute_mourn_1): New. (extended_remote_mourn): Use it. (extended_async_remote_mourn, extended_remote_run): New. (extended_remote_create_inferior_1): New. (extended_remote_create_inferior): Use it. (extended_remote_async_create_inferior): Likewise. (remote_xfer_partial): Skip for non-executing targets. (init_extended_remote_ops): Set to_detach and to_attach. (init_extended_async_remote_ops): Likewise. Use extended_async_remote_mourn. (_initialize_remote): Register vAttach, vRun, and set remote exec-file. * NEWS: Mention vAttach, vRun, and gdbserver extended-remote support. * gdb.server/ext-attach.c, gdb.server/ext-attach.exp, gdb.server/ext-run.exp: New files. * lib/gdbserver-support.exp (gdbserver_download): New. (gdbserver_start): New. Update gdbserver expected output. (gdbserver_spawn): Use them. (gdbserver_start_extended): New. * gdb.texinfo (Using the `gdbserver' Program): Add security warning. Rearrange into subsections and subsubsections. Document --multi and --debug. Correct --with-sysroot typo. Update --attach usage. Make load reference clearer. Document monitor exit. (Remote Configuration): Document set remote exec-file, attach-packet, and run-packet. (Packets): Document vAttach and vRun.
151 lines
5.9 KiB
Text
151 lines
5.9 KiB
Text
README for GDBserver & GDBreplay
|
|
by Stu Grossman and Fred Fish
|
|
|
|
Introduction:
|
|
|
|
This is GDBserver, a remote server for Un*x-like systems. It can be used to
|
|
control the execution of a program on a target system from a GDB on a different
|
|
host. GDB and GDBserver communicate using the standard remote serial protocol
|
|
implemented in remote.c, and various *-stub.c files. They communicate via
|
|
either a serial line or a TCP connection.
|
|
|
|
For more information about GDBserver, see the GDB manual.
|
|
|
|
Usage (server (target) side):
|
|
|
|
First, you need to have a copy of the program you want to debug put onto
|
|
the target system. The program can be stripped to save space if needed, as
|
|
GDBserver doesn't care about symbols. All symbol handling is taken care of by
|
|
the GDB running on the host system.
|
|
|
|
To use the server, you log on to the target system, and run the `gdbserver'
|
|
program. You must tell it (a) how to communicate with GDB, (b) the name of
|
|
your program, and (c) its arguments. The general syntax is:
|
|
|
|
target> gdbserver COMM PROGRAM [ARGS ...]
|
|
|
|
For example, using a serial port, you might say:
|
|
|
|
target> gdbserver /dev/com1 emacs foo.txt
|
|
|
|
This tells gdbserver to debug emacs with an argument of foo.txt, and to
|
|
communicate with GDB via /dev/com1. Gdbserver now waits patiently for the
|
|
host GDB to communicate with it.
|
|
|
|
To use a TCP connection, you could say:
|
|
|
|
target> gdbserver host:2345 emacs foo.txt
|
|
|
|
This says pretty much the same thing as the last example, except that we are
|
|
going to communicate with the host GDB via TCP. The `host:2345' argument means
|
|
that we are expecting to see a TCP connection from `host' to local TCP port
|
|
2345. (Currently, the `host' part is ignored.) You can choose any number you
|
|
want for the port number as long as it does not conflict with any existing TCP
|
|
ports on the target system. This same port number must be used in the host
|
|
GDBs `target remote' command, which will be described shortly. Note that if
|
|
you chose a port number that conflicts with another service, gdbserver will
|
|
print an error message and exit.
|
|
|
|
On some targets, gdbserver can also attach to running programs. This is
|
|
accomplished via the --attach argument. The syntax is:
|
|
|
|
target> gdbserver --attach COMM PID
|
|
|
|
PID is the process ID of a currently running process. It isn't necessary
|
|
to point gdbserver at a binary for the running process.
|
|
|
|
Usage (host side):
|
|
|
|
You need an unstripped copy of the target program on your host system, since
|
|
GDB needs to examine it's symbol tables and such. Start up GDB as you normally
|
|
would, with the target program as the first argument. (You may need to use the
|
|
--baud option if the serial line is running at anything except 9600 baud.)
|
|
Ie: `gdb TARGET-PROG', or `gdb --baud BAUD TARGET-PROG'. After that, the only
|
|
new command you need to know about is `target remote'. It's argument is either
|
|
a device name (usually a serial device, like `/dev/ttyb'), or a HOST:PORT
|
|
descriptor. For example:
|
|
|
|
(gdb) target remote /dev/ttyb
|
|
|
|
communicates with the server via serial line /dev/ttyb, and:
|
|
|
|
(gdb) target remote the-target:2345
|
|
|
|
communicates via a TCP connection to port 2345 on host `the-target', where
|
|
you previously started up gdbserver with the same port number. Note that for
|
|
TCP connections, you must start up gdbserver prior to using the `target remote'
|
|
command, otherwise you may get an error that looks something like
|
|
`Connection refused'.
|
|
|
|
Building gdbserver:
|
|
|
|
The supported targets as of November 2006 are:
|
|
arm-*-linux*
|
|
crisv32-*-linux*
|
|
cris-*-linux*
|
|
i[34567]86-*-cygwin*
|
|
i[34567]86-*-linux*
|
|
i[34567]86-*-mingw*
|
|
ia64-*-linux*
|
|
m32r*-*-linux*
|
|
m68*-*-linux*
|
|
m68*-*-uclinux*
|
|
mips*64*-*-linux*
|
|
mips*-*-linux*
|
|
powerpc[64]-*-linux*
|
|
s390[x]-*-linux*
|
|
sh-*-linux*
|
|
spu*-*-*
|
|
x86_64-*-linux*
|
|
xscale*-*-linux*
|
|
|
|
Configuring gdbserver you should specify the same machine for host and
|
|
target (which are the machine that gdbserver is going to run on. This
|
|
is not the same as the machine that gdb is going to run on; building
|
|
gdbserver automatically as part of building a whole tree of tools does
|
|
not currently work if cross-compilation is involved (we don't get the
|
|
right CC in the Makefile, to start with)).
|
|
|
|
Building gdbserver for your target is very straightforward. If you build
|
|
GDB natively on a target which gdbserver supports, it will be built
|
|
automatically when you build GDB. You can also build just gdbserver:
|
|
|
|
% mkdir obj
|
|
% cd obj
|
|
% path-to-gdbserver-sources/configure
|
|
% make
|
|
|
|
If you prefer to cross-compile to your target, then you can also build
|
|
gdbserver that way. In a Bourne shell, for example:
|
|
|
|
% export CC=your-cross-compiler
|
|
% path-to-gdbserver-sources/configure your-target-name
|
|
% make
|
|
|
|
Using GDBreplay:
|
|
|
|
A special hacked down version of gdbserver can be used to replay remote
|
|
debug log files created by gdb. Before using the gdb "target" command to
|
|
initiate a remote debug session, use "set remotelogfile <filename>" to tell
|
|
gdb that you want to make a recording of the serial or tcp session. Note
|
|
that when replaying the session, gdb communicates with gdbreplay via tcp,
|
|
regardless of whether the original session was via a serial link or tcp.
|
|
|
|
Once you are done with the remote debug session, start gdbreplay and
|
|
tell it the name of the log file and the host and port number that gdb
|
|
should connect to (typically the same as the host running gdb):
|
|
|
|
$ gdbreplay logfile host:port
|
|
|
|
Then start gdb (preferably in a different screen or window) and use the
|
|
"target" command to connect to gdbreplay:
|
|
|
|
(gdb) target remote host:port
|
|
|
|
Repeat the same sequence of user commands to gdb that you gave in the
|
|
original debug session. Gdb should not be able to tell that it is talking
|
|
to gdbreplay rather than a real target, all other things being equal. Note
|
|
that gdbreplay echos the command lines to stderr, as well as the contents of
|
|
the packets it sends and receives. The last command echoed by gdbreplay is
|
|
the next command that needs to be typed to gdb to continue the session in
|
|
sync with the original session.
|