[ob] Eliminate another gdb_suppress_entire_file

[ob] Eliminate another gdb_suppress_entire_file

[Daniel Jacobowitz]

There's a few versions of GCC 4.1 which can't compile gdb.base/store.c. It
was eventually fixed on the release branch, but I happen to be testing a
version where it's broken.  I've been making this change globally as the
function in question pops up to bite me.

Tested, committed.

-- 
Daniel Jacobowitz
CodeSourcery

2006-06-22  Daniel Jacobowitz  <dan@codesourcery.com>

	* gdb.base/store.exp: Don't use gdb_suppress_entire_file.

Index: gdb-20060226/gdb/testsuite/gdb.base/store.exp
===================================================================
--- gdb-20060226.orig/gdb/testsuite/gdb.base/store.exp	2004-08-04 07:59:56.000000000 -0700
+++ gdb-20060226/gdb/testsuite/gdb.base/store.exp	2006-06-13 20:57:13.000000000 -0700
@@ -30,7 +30,8 @@ set testfile "store"
 set srcfile ${testfile}.c
 set binfile ${objdir}/${subdir}/${testfile}
 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
-    gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+    untested store.exp
+    return -1
 }
 
 if [get_compiler_info ${binfile}] {

Re: [ob] Eliminate another gdb_suppress_entire_file

[Joel Brobecker]

> There's a few versions of GCC 4.1 which can't compile gdb.base/store.c. It
> was eventually fixed on the release branch, but I happen to be testing a
> version where it's broken.  I've been making this change globally as the
> function in question pops up to bite me.

Should we try to remove all the instances of gdb_suppress_entire_file?
I don't remember if there are some cases where it's legit to use them.

Thanks,
-- 
Joel

Re: [ob] Eliminate another gdb_suppress_entire_file

[Daniel Jacobowitz]

On Thu, Jun 22, 2006 at 08:10:29PM -0700, Joel Brobecker wrote:
> > There's a few versions of GCC 4.1 which can't compile gdb.base/store.c. It
> > was eventually fixed on the release branch, but I happen to be testing a
> > version where it's broken.  I've been making this change globally as the
> > function in question pops up to bite me.
> 
> Should we try to remove all the instances of gdb_suppress_entire_file?
> I don't remember if there are some cases where it's legit to use them.

I'd be in favor.

It's not a bad idea, really.  But the way the GDB testsuite is layed
out, I think it's impractical - and I know that in practice it doesn't
work, because it will always provoke an ERROR: Gdb did not load after
10 seconds (or something similar to that).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [ob] Eliminate another gdb_suppress_entire_file

[Joel Brobecker]

> > Should we try to remove all the instances of gdb_suppress_entire_file?
> > I don't remember if there are some cases where it's legit to use them.
> 
> I'd be in favor.
> 
> It's not a bad idea, really.  But the way the GDB testsuite is layed
> out, I think it's impractical - and I know that in practice it doesn't
> work, because it will always provoke an ERROR: Gdb did not load after
> 10 seconds (or something similar to that).

Oh ho, I just did a quick grep, and found 352 occurences.
That's a lot of work... I wonder if we could do that in a mechanical
way. It seems as though replacing this by an error followed by a return
would be OK, but not ideal. 

Hmmm. Perhaps a first step to stop any potential spread would be to
rename it deprecated_gdb_suppress_entire_file.

-- 
Joel

Re: [ob] Eliminate another gdb_suppress_entire_file

[Daniel Jacobowitz]

On Thu, Jun 22, 2006 at 08:35:31PM -0700, Joel Brobecker wrote:
> Oh ho, I just did a quick grep, and found 352 occurences.
> That's a lot of work... I wonder if we could do that in a mechanical
> way. It seems as though replacing this by an error followed by a return
> would be OK, but not ideal. 

I've been using untested followed by return.  Why wouldn't that be
ideal?

> Hmmm. Perhaps a first step to stop any potential spread would be to
> rename it deprecated_gdb_suppress_entire_file.

Just as much work as changing it, really...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [ob] Eliminate another gdb_suppress_entire_file

[Joel Brobecker]

> I've been using untested followed by return.  Why wouldn't that be
> ideal?

It's actually pretty good. I think in some cases unsupported might
be a better choice, but I like untested too, because it's always
going to be true...

I see in your patch that you used the name of the .exp file as
the argument of untested. Should we do that, or should we try
to preserve the string we previously used with gdb_suppress_entire_file?

-- 
Joel

Re: [ob] Eliminate another gdb_suppress_entire_file

[Daniel Jacobowitz]

On Thu, Jun 22, 2006 at 09:03:52PM -0700, Joel Brobecker wrote:
> > I've been using untested followed by return.  Why wouldn't that be
> > ideal?
> 
> It's actually pretty good. I think in some cases unsupported might
> be a better choice, but I like untested too, because it's always
> going to be true...
> 
> I see in your patch that you used the name of the .exp file as
> the argument of untested. Should we do that, or should we try
> to preserve the string we previously used with gdb_suppress_entire_file?

Really, I don't think it matters :-)

-- 
Daniel Jacobowitz
CodeSourcery