Move gdbserver to top level

This patch moves gdbserver to the top level.

This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport.  Changing this will
be done in a separate patch.

[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score.  This makes
sense, because there is apparently not actually a gdbserver port here.

[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.

[v4] This version adds documentation and removes some unnecessary
top-level dependencies.

[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.

Tested by the buildbot.

ChangeLog
2020-02-07  Tom Tromey  <tom@tromey.com>
	    Pedro Alves  <palves@redhat.com>

	* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
	* gdbserver: New directory, moved from gdb/gdbserver.
	* configure.ac (host_tools): Add gdbserver.
	Only build gdbserver on certain systems.
	* Makefile.in, configure: Rebuild.
	* Makefile.def (host_modules, dependencies): Add gdbserver.
	* MAINTAINERS: Add gdbserver.

gdb/ChangeLog
2020-02-07  Tom Tromey  <tom@tromey.com>

	* README: Update gdbserver documentation.
	* gdbserver: Move to top level.
	* configure.tgt (build_gdbserver): Remove.
	* configure.ac: Remove --enable-gdbserver.
	* configure: Rebuild.
	* Makefile.in (distclean): Don't mention gdbserver.

Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e

gdbserver/README

@@ -0,0 +1,149 @@
+		   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*
+	bfin-*-uclinux
+	bfin-*-linux-uclibc
+	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*
+
+Building GDBserver for your host is very straightforward.  If you build
+GDB natively on a host which GDBserver supports, it will be built
+automatically when you build GDB.  You can also build just GDBserver:
+
+	% mkdir obj
+	% cd obj
+	% path-to-toplevel-sources/configure --disable-gdb
+	% make all-gdbserver
+
+(If you have a combined binutils+gdb tree, you may want to also
+disable other directories when configuring, e.g., binutils, gas, gold,
+gprof, and ld.)
+
+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-topevel-sources/configure your-target-name --disable-gdb
+	% 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.