On 02/08/2012 09:27 AM, Jack Howarth wrote:
On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
On 02/08/2012 08:37 AM, Iain Sandoe wrote:
Well - it depends. You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is. A
definite finishes-never would be a FAIL of course. The question is
on which
side to err.
There was also some discussion about reducing the amount of log-file
output (which might help too).
Did that ever get anywhere/who would be willing to decide what could
be dropped from the output?
Iain
For a start we could comment out the
disp/i $pc
command in the simulate-thread.gdb script file. I'd leave it there as
a comment to make it easy to turn back on when needed.
Andrew,
Eliminating the "disp/i $pc" in the simulate-thread.gdb script file
is insufficient to reduce the execution time below 10 seconds. What is
the next thing we can prune?
Jack
no, it wont change the time, just reduce the size of the log file.
The only way to reduce the time below 10 seconds would be to change the
test case to run less time, but I'd rather leave them as they are. They
did catch one very tricky case for me.
I propose increasing the time to 20 seconds and reduce the log file. I
believe the timeout as made really short because of the size of the log
file when the timeout was needed. I htink it was an arbitrary number.
Doubling the execution time and halving the size of the log file should
put us about where we were.
Im even fine abandoning most of the log file if need be as well... Its
really pass or fail that I care about and a fail usually requires hand
investigation anyway
The other thing we can do is to only run the test with -O0 and -O3.
right now they run with -O0, -O1, -O2, -O3, -Os. I don't think the
other options really add much.
Andrew
