Testsuite failures in gdb.gdb/selftest.exp

Testsuite failures in gdb.gdb/selftest.exp

[Andreas Schwab]

With heavy optimizations there can be even more code reordering, causing
spurious failures in do_steps_and_nexts.

The quit_flag case was seen on ppc, the gdb_std{out,err} cases on ia64.

Andreas.

2007-01-31  Andreas Schwab  <schwab@suse.de>

	* gdb.gdb/selftest.exp (do_steps_and_nexts): Add more matches.

--- gdb/testsuite/gdb.gdb/selftest.exp.~1.10.~	2007-01-10 11:18:59.000000000 +0100
+++ gdb/testsuite/gdb.gdb/selftest.exp	2007-01-31 18:02:16.000000000 +0100
@@ -177,6 +177,10 @@ proc do_steps_and_nexts {} {
 		set description "step over ndir initialization"
 		set command "step"
 	    }
+	    -re ".*quit_flag = 0.*$gdb_prompt $" {
+		set description "step over quit_flag initialization"
+		set command "step"
+	    }
 	    -re ".*instream = stdin.*$gdb_prompt $" {
 		set description "step over instream initialization"
 		set command "step"
@@ -185,6 +189,14 @@ proc do_steps_and_nexts {} {
 		set description "next over getcwd"
 		set command "next"
 	    }
+	    -re ".*gdb_stdout = stdio_fileopen .stdout.;.*$gdb_prompt $" {
+		set description "step over gdb_stdout initialization"
+		set command "step"
+	    }
+	    -re ".*gdb_stderr = stdio_fileopen .stderr.;.*$gdb_prompt $" {
+		set description "step over gdb_stderr initialization"
+		set command "step"
+	    }
 	    -re "\[ \t\]+\{\r\n$gdb_prompt $" {
 		setup_xfail "mips-*-irix5*"
 		fail "$description ended up at odd location"

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.gdb/selftest.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 06:12:37PM +0100, Andreas Schwab wrote:
> With heavy optimizations there can be even more code reordering, causing
> spurious failures in do_steps_and_nexts.
> 
> The quit_flag case was seen on ppc, the gdb_std{out,err} cases on ia64.

You may have checked this already but... are these sensible lines to
have reached, given what's executing?  Or are these additional
symptoms of gcc/26475 or a similar problem?

I can't see how a non-interprocedural optimizer would do anything
useful with any of those statements across an extern call to xmalloc.
But on ia64 it might be e.g. computing the address of stdout before
the call, given how many registers there are.


-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.gdb/selftest.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 06:12:37PM +0100, Andreas Schwab wrote:
>> With heavy optimizations there can be even more code reordering, causing
>> spurious failures in do_steps_and_nexts.
>> 
>> The quit_flag case was seen on ppc, the gdb_std{out,err} cases on ia64.
>
> You may have checked this already but... are these sensible lines to
> have reached, given what's executing? Or are these additional
> symptoms of gcc/26475 or a similar problem?

On ia64 the address of gdb_stdout/gdb_stderr (together with a few other
variables) is definitely computed very early in the function.  The
quit_flag case could indeed be an instance of the gcc bug.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.gdb/selftest.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 06:55:36PM +0100, Andreas Schwab wrote:
> On ia64 the address of gdb_stdout/gdb_stderr (together with a few other
> variables) is definitely computed very early in the function.  The
> quit_flag case could indeed be an instance of the gcc bug.

Could you just check in the ia64 bits, then, until you have a chance to
check on PPC?

I realize it doesn't make much difference, but I'd like to have at
least what tests we can for this GCC issue in the GDB testsuite.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.gdb/selftest.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 06:55:36PM +0100, Andreas Schwab wrote:
>> On ia64 the address of gdb_stdout/gdb_stderr (together with a few other
>> variables) is definitely computed very early in the function.  The
>> quit_flag case could indeed be an instance of the gcc bug.
>
> Could you just check in the ia64 bits, then, until you have a chance to
> check on PPC?

Looking a bit closer the ppc issue is definitely not an instance of the
gcc bug.  The register that holds the value for quit_flag is set very
early in the function.

 110:   3b 80 00 00     li      r28,0
[...]
 160:   3d 60 00 00     lis     r11,0
                        162: R_PPC_ADDR16_HA    quit_flag
[...]
 16c:   93 8b 00 00     stw     r28,0(r11)
                        16e: R_PPC_ADDR16_LO    quit_flag

Thus the line number information generated by gcc looks correct (address
110 is the first insn after the prologue).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.gdb/selftest.exp

[Daniel Jacobowitz]

On Wed, Jan 31, 2007 at 08:11:52PM +0100, Andreas Schwab wrote:
> Thus the line number information generated by gcc looks correct (address
> 110 is the first insn after the prologue).

It could still be a GCC bug - if the zero is reused for more things
than just that one store, as I hope it will be, then that's a perverse
line number to choose.  But that's good enough; thank you for checking.

Patch is OK.

Eli, to answer your question: this is gdb.gdb/selftest.exp, which
debugs the just-compiled GDB binary (which was probably compiled
with optimization).  It's one of the few tests of optimized code
that we have in the testsuite.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Testsuite failures in gdb.gdb/selftest.exp

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jan 31, 2007 at 08:11:52PM +0100, Andreas Schwab wrote:
>> Thus the line number information generated by gcc looks correct (address
>> 110 is the first insn after the prologue).
>
> It could still be a GCC bug - if the zero is reused for more things
> than just that one store, as I hope it will be, then that's a perverse
> line number to choose.  But that's good enough; thank you for checking.

The register is also used for "line[0] = '\0'".

> Patch is OK.

Thanks.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Testsuite failures in gdb.gdb/selftest.exp

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Wed, 31 Jan 2007 18:12:37 +0100
> 
> With heavy optimizations there can be even more code reordering, causing
> spurious failures in do_steps_and_nexts.

Isn't it better to just disable optimizations?  This is a GDB
testsuite, not a compiler testsuite.

Or am I missing something?