This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb_suppress_entire_file must die


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]