]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/testsuite: move getting_compiler_info to front of gdb_compile
authorNils-Christian Kempke <nils-christian.kempke@intel.com>
Tue, 31 May 2022 14:43:43 +0000 (16:43 +0200)
committerNils-Christian Kempke <nils-christian.kempke@intel.com>
Tue, 31 May 2022 14:44:54 +0000 (16:44 +0200)
commit7ce4a6d1846fae44b25c1733164451a316f22567
treee0a7d8f8219d040498dc949960b52ce35102cd28
parentc8df10fc707ec1f30767d96f508a99b8c0f901aa
gdb/testsuite: move getting_compiler_info to front of gdb_compile

The procedure gdb_compile queries its options via

   [lsearch -exact $options getting_compiler_info]

to check whether or not it was called in with the option
getting_compiler_info.  If it was called with this option it would
preprocess some test input to try and figure out the actual compiler
version of the compiler used.  While doing this we cannot again try to
figure out the current compiler version via the 'getting_compiler_info'
option as this would cause infinite recursion.  As some parts of the
procedure do recursively test for the compiler version to e.g. set
certain flags, at several places gdb_compile there are checks for the
getting_compiler_info option needed.

In the procedure, there was already a variable 'getting_compiler_info'
which was set to the result of the 'lsearch' query and used instead of
again and again looking for getting_compiler_info in the procedure
options.  But, this variable was actually set too late within the code.
This lead to a mixture of querying 'getting_compiler_info' or
doing an lserach on the options passed to the procedure.

I found this inconsistent and instead moved the variable
getting_compiler_info to the front of the procedure.  It is set to true
or false depending on whether or not the argument is found in the
procedure's options (just as before) and queried instead of doing an
lsearch on the procedure options in the rest of the procedure.
gdb/testsuite/lib/gdb.exp