gdb/
* README: Use consistent `GDB' and `GDBserver' spellings. gdb/gdbserver/ * README: Use consistent `GDB' and `GDBserver' spellings.
This commit is contained in:
parent
0dfb946f50
commit
1915ef4f3a
@ -1,3 +1,7 @@
|
||||
2010-05-02 Pedro Alves <pedro@codesourcery.com>
|
||||
|
||||
* README: Use consistent `GDB' and `GDBserver' spellings.
|
||||
|
||||
2010-05-02 Jan Kratochvil <jan.kratochvil@redhat.com>
|
||||
|
||||
* cli/cli-dump.h (parse_and_eval_with_error): Remove the declaration.
|
||||
|
18
gdb/README
18
gdb/README
@ -22,8 +22,8 @@ files, the BFD ("binary file description") library, the readline
|
||||
library, and other libraries all have directories of their own
|
||||
underneath the gdb-6.3 directory. The idea is that a variety of GNU
|
||||
tools can share a common copy of these things. Be aware of variation
|
||||
over time--for example don't try to build gdb with a copy of bfd from
|
||||
a release other than the gdb release (such as a binutils release),
|
||||
over time--for example don't try to build GDB with a copy of bfd from
|
||||
a release other than the GDB release (such as a binutils release),
|
||||
especially if the releases are more than a few weeks apart.
|
||||
Configuration scripts and makefiles exist to cruise up and down this
|
||||
directory tree and automatically build all the pieces in the right
|
||||
@ -73,10 +73,10 @@ argument, e.g., `./configure sun4' or `./configure decstation'.
|
||||
/berman/migchain/source/gdb-6.3/configure # RIGHT
|
||||
/berman/migchain/source/gdb-6.3/gdb/configure # WRONG
|
||||
|
||||
The gdb package contains several subdirectories, such as 'gdb',
|
||||
The GDB package contains several subdirectories, such as 'gdb',
|
||||
'bfd', and 'readline'. If your 'configure' line ends in
|
||||
'gdb-6.3/gdb/configure', then you are configuring only the gdb
|
||||
subdirectory, not the whole gdb package. This leads to build errors
|
||||
subdirectory, not the whole GDB package. This leads to build errors
|
||||
such as:
|
||||
|
||||
make: *** No rule to make target `../bfd/bfd.h', needed by `gdb.o'. Stop.
|
||||
@ -88,7 +88,7 @@ Bugs' section below; there are a few known problems.
|
||||
C compiler for your system, you may be able to download and install
|
||||
the GNU CC compiler. It is available via anonymous FTP from the
|
||||
directory `ftp://ftp.gnu.org/pub/gnu/gcc'. GDB also requires an ISO
|
||||
C standard library. The GDB remote server, gdbserver, builds with some
|
||||
C standard library. The GDB remote server, GDBserver, builds with some
|
||||
non-ISO standard libraries - e.g. for Windows CE.
|
||||
|
||||
GDB uses Expat, an XML parsing library, to implement some target-specific
|
||||
@ -545,12 +545,12 @@ standalone on an m68k, i386, or SPARC cpu and communicate properly
|
||||
with the remote.c stub over a serial line.
|
||||
|
||||
The directory gdb/gdbserver/ contains `gdbserver', a program that
|
||||
allows remote debugging for Unix applications. gdbserver is only
|
||||
allows remote debugging for Unix applications. GDBserver is only
|
||||
supported for some native configurations, including Sun 3, Sun 4, and
|
||||
Linux.
|
||||
The file gdb/gdbserver/README includes further notes on gdbserver; in
|
||||
particular, it explains how to build gdbserver for cross-debugging
|
||||
(where gdbserver runs on the target machine, which is of a different
|
||||
The file gdb/gdbserver/README includes further notes on GDBserver; in
|
||||
particular, it explains how to build GDBserver for cross-debugging
|
||||
(where GDBserver runs on the target machine, which is of a different
|
||||
architecture than the host machine running GDB).
|
||||
|
||||
There are a number of remote interfaces for talking to existing ROM
|
||||
|
@ -1,3 +1,7 @@
|
||||
2010-05-02 Pedro Alves <pedro@codesourcery.com>
|
||||
|
||||
* README: Use consistent `GDB' and `GDBserver' spellings.
|
||||
|
||||
2010-05-02 Pedro Alves <pedro@codesourcery.com>
|
||||
|
||||
* linux-low.c (linux_kill_one_lwp): Assume the lwp is stopped.
|
||||
|
@ -28,8 +28,8 @@ 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
|
||||
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:
|
||||
@ -43,16 +43,16 @@ that we are expecting to see a TCP connection from `host' to local TCP port
|
||||
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
|
||||
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
|
||||
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.
|
||||
to point GDBserver at a binary for the running process.
|
||||
|
||||
Usage (host side):
|
||||
|
||||
@ -72,12 +72,12 @@ 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'
|
||||
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:
|
||||
Building GDBserver:
|
||||
|
||||
The supported targets as of November 2006 are:
|
||||
arm-*-linux*
|
||||
@ -99,16 +99,16 @@ The supported targets as of November 2006 are:
|
||||
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
|
||||
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:
|
||||
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
|
||||
@ -116,7 +116,7 @@ automatically when you build GDB. You can also build just gdbserver:
|
||||
% make
|
||||
|
||||
If you prefer to cross-compile to your target, then you can also build
|
||||
gdbserver that way. In a Bourne shell, for example:
|
||||
GDBserver that way. In a Bourne shell, for example:
|
||||
|
||||
% export CC=your-cross-compiler
|
||||
% path-to-gdbserver-sources/configure your-target-name
|
||||
@ -124,28 +124,28 @@ gdbserver that way. In a Bourne shell, for example:
|
||||
|
||||
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
|
||||
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,
|
||||
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):
|
||||
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:
|
||||
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
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user