mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00
5e92f71a86
This introduces parallel mode for the test suite. It doesn't fully work yet in the sense that if you do a fully parallel run, you will encounter some file-name clashes, but this has to start somewhere, and it seemed best to add some infrastructure now, so that you can follow along and test subsequent patches if you care to. This patch has two parts. First, it checks for the GDB_PARALLEL variable. If this is set (say, on the runtest command line), then the test suite assumes "parallel mode". In this mode, files are put into a subdirectory named after the test. That is, for DIR/TEST.exp, the outputs are put into ./outputs/DIR/TEST/. This first part has various follow-on changes coming in subsequent patches. This is why the code in this patch also makes "temp" and "cache" directories. Second, this adds an "inotify" mode. If you have the inotifywait command (part of inotify-tools), you can set the GDB_INOTIFY variable. This will tell the test suite to watch for changes outside of the allowed output directories. This mode is useful for debugging the test suite, as it issues a report whenever a possibly parallel-unsafe file open is done. 2013-08-13 Tom Tromey <tromey@redhat.com> Yao Qi <yao@codesourcery.com> * lib/cache.exp (gdb_do_cache): Handle GDB_PARALLEL. * lib/gdb.exp: Handle GDB_PARALLEL. (default_gdb_version): Kill inotify_pid if it exists. (default_gdb_exit): Emit warning if the inotify log is not empty. (standard_output_file): Respect GDB_PARALLEL. (standard_temp_file): Likewise. (gdb_init): Start inotifywait if requested. * gdbint.texinfo (Testsuite): Use @table, not @itemize. Document GDB_PARALLEL and GDB_INOTIFY.
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.