forked from Imagelibrary/binutils-gdb
7817ea4614
This patch removes gdb_download in favor of gdb_remote_download, since they are very close in functionality. Also, in preparation for the following patch about shared library handling during tests, it improves gdb_remote_download so that it uses standard_output_file for any destination board that is local, not only host. If the destination board is remote, gdb_remote_download will use the standard remote_download from DejaGnu, resulting in the file being transferred on the remote system. If the destination is local, gdb_remote_download will copy the file to the standard test directory (found using standard_output_file). Tcl's file copy seems to handle gracefully cases where the source file is the same as the destination, so I don't think it's necessary to check for that case ourselves, as a previous version of the patch did. I'd prefer to keep the name gdb_download instead of gdb_remote_download, since I don't like the fact that gdb_remote_download implies that the destination is remote, when it's not always the case. However, gdb_remote_download is used at many more places than gdb_download, so it's easier to reuse that. Also, since it's a wrapper around DejaGnu's remote_download, it might be better to keep that name. I don't know. I ran the testsuite native, with native-gdbserver and with a remote gdbserver, and didn't see any related failure. gdb/testsuite/ChangeLog: * gdb.base/jit-so.exp: Use gdb_remote_download instead of gdb_download. Use it even if the target is not remote. * gdb.base/jit.exp (compile_jit_test): Likewise. * lib/gdb.exp (gdb_remote_download): Copy files to the standard output directory if the destination board is local, otherwise use the standard remote_download from DejaGnu. (gdb_download): Remove. (gdb_load_shlibs): Use gdb_remote_download instead of gdb_download. * lib/gdbserver-support.exp (gdbserver_download_current_prog): Use gdb_remote_download instead of gdb_download. Use it even if the target is not remote. * lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download instead of gdb_download.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.