mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-12-05 15:15:42 +00:00
d09eba07ca
While running tests on Windows with:
$ make check-parallel RUNTESTFLAGS="-v"
I noticed that get_compiler_info was invoking the compiler over and
over for each testcase, even though the result is supposed to be
cached.
This isn't normally very visible in gdb.log, because we suppress it
there:
# Run $ifile through the right preprocessor.
# Toggle gdb.log to keep the compiler output out of the log.
set saved_log [log_file -info]
log_file
...
I'm not sure it's a good idea to do that suppression, BTW. I was very
confused when I couldn't find the compiler invocation in gdb.log, and
it took me a while to notice that code.
The reason get_compiler_info in parallel mode isn't hitting the cache
is that in that mode each testcase runs under its own expect/dejagnu
process, and the way get_compiler_info caches results currently
doesn't handle that -- the result is simply cached in a global
variable, which is private to each expect.
So improve this by switching get_compiler_info's caching mechanism to
gdb_caching_proc instead, so that results are cached across parallel
invocations of dejagnu.
On an x86-64 GNU/Linux run with "make check-parallel -j32", before the
patch I get 2223 calls to get_compiler_info that result in a compiler
invocation. After the patch, I get 7.
On GNU/Linux, those compiler invocations don't cost much, but on
Windows, they add up. On my machine each invocation takes around
500ms to 700ms. Here is one representative run:
$ time x86_64-w64-mingw32-gcc \
/c/msys2/home/alves/gdb/build-testsuite/temp/14826/compiler.c \
-fdiagnostics-color=never -E
...
real 0m0.639s
user 0m0.061s
sys 0m0.141s
This reference to a 'compiler_info' global:
# N.B. compiler_info is intended to be local to this file.
# Call test_compiler_info with no arguments to fetch its value.
# Yes, this is counterintuitive when there's get_compiler_info,
# but that's the current API.
if [info exists compiler_info] {
unset compiler_info
}
is outdated, even before this patch, as "compiler_info" is a local
variable in get_compiler_info. Remove all that code.
Since test_compiler_info now calls get_compiler_info directly, the
"Requires get_compiler_info" comments in skip_inline_frame_tests and
skip_inline_var_tests are no longer accurate. Remove them.
test_compiler_info's intro comment is also outdated; improve it.
Changing the return value of get_compiler_info to be the
'compiler_info' string directly instead of 0/-1 was simpler. It would
be possible to support the current 0/-1 interface by making
get_compiler_info_1 still return the 'compiler_info' string, and then
having the get_compiler_info wrapper convert to 0/-1, and I considered
doing that. But the only caller of get_compiler_info outside gdb.exp
is gdb.python/py-event-load.exp, and it seems that one simply crossed
wires with:
commit 9704b8b4bc
gdb/testsuite: remove unneeded calls to get_compiler_info
as the test as added at roughly the same time as that commit.
So simply remove that call in gdb.python/py-event-load.exp, otherwise
we get something like:
ERROR: -------------------------------------------
ERROR: in testcase src/gdb/testsuite/gdb.python/py-event-load.exp
ERROR: expected boolean value but got "gcc-13-3-0"
ERROR: tcl error code TCL VALUE NUMBER
ERROR: tcl error info:
expected boolean value but got "gcc-13-3-0"
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ia3d3dc34f7cdcf9a2013f1054128c62a108eabfb
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, and so on. 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.