This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb_suppress_entire_file must die
- From: Jim Blandy <jimb at redhat dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: gdb at sources dot redhat dot com
- Date: 04 Feb 2003 00:02:06 -0500
- Subject: Re: gdb_suppress_entire_file must die
- References: <200302040411.h144B0Z05427@duracef.shout.net>
Michael Elizabeth Chastain <mec@shout.net> writes:
> gdb_suppress_entire_file really gets my goat.
>
> I start with this:
>
> # 2003-20-01/native,HEAD,HEAD,2.13.2.1,dwarf-2/gdb.sum
> Running /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.c++/casts.exp ...
> UNRESOLVED: gdb.c++/casts.exp: cast base class pointer to derived class pointer
> PASS: gdb.c++/casts.exp: let compiler cast base class pointer to derived class pointer
>
> So I go looking for problems with gdb.c++/casts.exp. But there's nothing
> wrong with gdb.c++/casts.exp in this configuration. It turns out the
> problem is that the last test script before this one was
> gdb.c++/anon-union.exp.
>
> gdb.c++/anon-union.exp makes gcc cough up an ICE (which I duly reported
> back on 2002-12-22). Then it calls gdb_suppress_entire_file, which sets
> some flaky global named 'suppress_flag' that cause a lot of cascade
> non-PASS results for the rest of anon-union.exp. Cascade failures are
> okay with me. But the 'suppress_flag' continues into the next script
> and that is NOT okay because I slice and dice the results and compare
> them with other configurations and these random UNRESOLVED results
> show up for innocent tests.
>
> I would really like to kill this 'file suppression' crap. Every place
> that says:
>
> if { [gdb_compile ... != "" } {
> gdb_suppress_entire_file "Testcase compile failed ..."
> }
>
> I want to say:
>
> if { [gdb_compile ... != "" } {
> perror "Testcase compile failed."
> continue
> }
>
> We don't have to do this all at once. I can just start doing this
> as needed, starting with gdb.c++/anon-union.exp.
>
> Alternatively, we can add more places to set and clear 'suppress_flag'
> inside lib/gdb.exp. But I honestly don't see any value to the
> suppression logic at all. Does anybody?
>
> How about it?
I had always thought that suppress_flag was a DejaGnu thing, not a
GDB-specific thing, so that DejaGnu could reset it when it went on to
the next file. But it's not. There's no reference to suppress_flag
in DejaGnu at all.
I'm not a heavy test suite output hacker (at least not by your and
Daniel J.'s standards), but perror and continue sounds good to me.
Everyone should check for ERROR anyway.