Re: Problems with dejagnu and c++ tests...

Michael Elizabeth Chastain
2004-02-04T22:31:11Z

ac> (aren't we trying to delete gcc_compiled? :-)

Yes. When the last reference to gcc_compiled goes away,
then we can remove the code that initializes it.

ac> Something based on CPP would be more robust, and avoid assumptions such
ac> as the target has output and can correctly compile / execute code.
ac> Consider what happens when trying to bring up a new GDB+GCC+....

We're running the test suite. If gdb_compile does not work,
or the resulting executables cannot be run, then the test script
cannot run its tests anyways.

Just look at the code in gdb.cp/ambiguous.exp or anywhere else that
calls get_compiler_info:

if [get_compiler_info ${binfile} "c++"] {
return -1;
}
...
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}
...
gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

get_compiler_info is always followed by gdb_compile.
get_compiler_info should use the same compiler as gdb_compile.

Also, read the comments at the beginning of get_compiler_info.
'Something based on CPP' has a lot of problems with any implementation
that I can think of.

gdb 6.0 had four different implementations:

most targets with c
most targets with c++
hpux|irix with c
hpux|irix with c++

"most targets with c" and "most targets with c++" depended on
a non-standard gcc extension, which is why the hpux|irix targets
needed special cases.

hpux|irix with c++ *did not work*. It used about 100 lines of special
code but did not even use the same compiler as gdb_compile, so it
invoked a different compiler and set the variables wrong.
That's what drove me to rewrite get_compiler_info in the first place.

Michael C