On 19/04/2010 01:45, Dave Korn wrote:
> Something strange, unexpected and a bit alarming happened:
For context, it is necessary to explain that I was testing a patch (target
i686-pc-linux-gnu running on FC10) that mechanically renamed a bunch of
functions matching "lto_elf_*" to match "lto_obj_*" instead, and updated their
callers, so I was very strongly expecting to see no change in the testresults.
Instead, I got:
>> -# of expected passes 72800
>> +# of expected passes 72799
> ... which turns out to be because:
>> -PASS: gcc.dg/guality/pr43479.c -O1 line 13 i == 6
>> +UNSUPPORTED: gcc.dg/guality/pr43479.c -O1 line 13 i == 6
So, I'm looking at the logs of the two tests, and here is the passing case:
> PASS: gcc.dg/guality/pr43479.c -O1 execution test
> Spawning: gdb -nx -nw -quiet -x pr43479.gdb ./pr43479.exe
> [?1034hBreakpoint 1 at 0x80483b7: file
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
>
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13 k++; /* { dg-final { gdb-test 13 "i" "6" } } */
> $1 = 6
> $2 = 6
> The program is running. Exit anyway? (y or n) [answered Y; input not from
> terminal]
> PASS: gcc.dg/guality/pr43479.c -O1 line 13 i == 6
... and here is what it did in the failing case:
> PASS: gcc.dg/guality/pr43479.c -O1 execution test
> Spawning: gdb -nx -nw -quiet -x pr43479.gdb ./pr43479.exe
> [?1034hBreakpoint 1 at 0x80483b7: file
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
>
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9fUNSUPPORTED:
> gcc.dg/guality/pr43479.c -O1 line 13 i == 6
Now, there is code in gcc/testsuite/lib/gcc-gdb-test.exp#gdb-test that looks
out for this condition:
> # Too old GDB
> -re "Unhandled dwarf expression|Error in sourced command file" {
> unsupported "$testname"
... so probably, it should have been treated as unsupported on both clean and
patched builds. Rebuilding the executables and reinvoking gdb on them and
running to the same breakpoint manually, produces identical results for the
patched and unpatched compilers: clean
> [da...@ubique gcc]$ /gnu/gcc/obj.clean/gcc/xgcc -B/gnu/gcc/obj.clean/gcc/
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c -O1 -g -lm -o
> ./pr43479.exe
> [da...@ubique gcc]$ gdb -nx -nw -quiet ./pr43479.exe
> (gdb) b 13
> Breakpoint 1 at 0x80483a7: file
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> (gdb) r
> Starting program: /gnu/gcc/obj.clean/gcc/testsuite/gcc/pr43479.exe
>
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13 k++; /* { dg-final { gdb-test 13 "i" "6" } } */
> (gdb)
versus patched:
> [da...@ubique gcc]$ /gnu/gcc/obj.patched/gcc/xgcc -B/gnu/gcc/obj.patched/gcc/
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c -O1 -g -lm -o
> ./pr43479.exe
> [da...@ubique gcc]$ gdb -nx -nw -quiet ./pr43479.exe
> (gdb) b 13
> Breakpoint 1 at 0x80483a7: file
> /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c, line 13.
> (gdb) r
> Starting program: /gnu/gcc/obj.patched/gcc/testsuite/gcc/pr43479.exe
>
> Breakpoint 1, foo (k=Unhandled dwarf expression opcode 0x9f
> ) at /gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/pr43479.c:13
> 13 k++; /* { dg-final { gdb-test 13 "i" "6" } } */
> (gdb)
Well, I think I can guess what happened here. (This often happens as a
side-effect of taking the time to clearly explain the problem in the form of a
mailing list post asking for help!) The code in gcc-gdb-test.exp that invokes
gdb and looks for output from it is structured like so:
remote_expect target [timeout_value] {
-re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
set first $expect_out(1,string)
set second $expect_out(2,string)
if { $first == $second } {
pass "$testname"
} else {
send_log "$first != $second\n"
fail "$testname"
}
remote_close target
return
}
# Too old GDB
-re "Unhandled dwarf expression|Error in sourced command file" {
unsupported "$testname"
remote_close target
return
}
timeout {
unsupported "$testname"
remote_close target
return
}
}
My theory is that, depending on system load, the stdout coming from gdb and
being received by remote_expect is getting received in chunks in some way, and
that, depending how far the expect-launched gdb and its inferior progress,
expect might receive either all the output, or only the first couple of lines.
If all the output turns up in one chunk, the code above will match on the
first -re expression, and give a PASS, despite the unhandled dwarf expression
opcdode; the second -re that tests for that will never get a chance to run.
On the other hand, when the system is under heavy load, and remote_expect
returns the first line or two of the output, without the final "$1 = 6" that
it's hoping to match in the first -re expression, the second -re this time
does get a chance to run and so the UNSUPPORTED result is returned.
So, should we move the second -re match above the first? I think all I
really need confirmed this stage is that not recognising the dwarf opcode
should take priority in causing an UNSUPPORTED result despite the fact that a
result is nonetheless available for the value of the variable being tested,
yes/no? If so, I'll send a patch.
cheers,
DaveK
