mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 12:34:43 +00:00
ad24bc3b50
We have a few tests that load core files, which depend on GDB not auto-loading the executable that matches the core file. One of these tests (corefile-buildid.exp) exercises GDB's ability to load the executable via the build-id links in the debug directory, while the other two tests are just written assuming that GDB hasn't auto-loaded the executable. In the next commit, GDB is going to get better at finding the executable for a core file, and as a consequence these tests could start to fail if the testsuite is being run using a compiler that adds build-ids by default, and is on a target (currently only Linux) with the improved executable auto-loading. To avoid these test failures, this commit updates some of the tests. coredump-filter.exp and corefile.exp are updated to unload the executable should it be auto-loaded. This means that the following output from GDB will match the expected patterns. If the executable wasn't auto-loaded then the new step to unload is harmless. The corefile-buildid.exp test needed some more significant changes. For this test it is important that the executable be moved aside so that GDB can't locate it, but we do still need the executable around somewhere, so that the debug directory can link to it. The point of the test is that the executable _should_ be auto-loaded, but using the debug directory, not using GDB's context parsing logic. While looking at this test I noticed two additional problems, first we were creating the core file more times than we needed. We only need to create one core file for each test binary (total two), while we previously created one core file for each style of debug info directory (total four). The extra core files should be identical, and were just overwriting each other, harmless, but still pointless work. The other problem is that after running an earlier test we modified the test binary in order to run a later test. This means it's not possible to manually re-run the first test as the binary for that test is destroyed. As part of the rewrite in this commit I've addressed these issues. This test does change many of the test names, but there should be no real changes in what is being tested after this commit. However, when the next commit is added, and GDB gets better at auto-loading the executable for a core file, these tests should still be testing what is expected.
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.