This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] -gused
On Friday, June 13, 2003, at 3:21 PM, Richard Henderson wrote:
On Fri, Jun 13, 2003 at 09:49:37AM -0700, Devang Patel wrote:
In gdb testsuite (at least in Darwin) there are few tests which
are not suitable for -gused by nature. Are you interested in gdb
testresults with -gused ? I will not be surprised if they are not
identical to -g.
I realize this. We just need to examine each difference and
see if it is indeed to be expected.
Finally I managed to set up one linux box to do gdb dejagnu testing.
First I ran tests without applying my patch using mainline sources.
I ran all tests for STABS only. I did not do any testing for DWARF.
gdb test summary before applying my patch:
=== gdb Summary ===
# of expected passes 8280
# of unexpected failures 193
# of unexpected successes 87
# of expected failures 63
# of known failures 9
# of unresolved testcases 17
# of unsupported tests 1
gdb test summary with -g option after applying my patch:
(without using -gused)
=== gdb Summary ===
# of expected passes 8288
# of unexpected failures 183
# of unexpected successes 87
# of expected failures 63
# of known failures 10
# of unresolved testcases 17
# of unsupported tests 1
So, it is good that my patch is not causing more failures.
But it is unexpected that my patch is reduing failures with -g.
I looked at the logs and all differences are related to threads.
I do not understand what is going on in this area, but here is
the diffs between failures.
30,38c30
< FAIL: gdb.threads/schedlock.exp: thread 0 ran (didn't run)
< FAIL: gdb.threads/schedlock.exp: step without lock does not change
thread (switched to thread 0)
< FAIL: gdb.threads/schedlock.exp: current thread stepped (didn't run)
< FAIL: gdb.threads/schedlock.exp: continue with lock does not change
thread (switched to thread 0)
< FAIL: gdb.threads/schedlock.exp: other thread 0 didn't run (ran)
< FAIL: gdb.threads/schedlock.exp: current thread ran (didn't run)
< FAIL: gdb.threads/schedlock.exp: step with lock does not change
thread (switched to thread 0)
< FAIL: gdb.threads/schedlock.exp: other thread 0 didn't run (stepping)
(ran)
< FAIL: gdb.threads/schedlock.exp: current thread stepped locked
(didn't run)
---
> FAIL: gdb.threads/schedlock.exp: thread 1 ran (didn't run)
I welcome any suggestion about how to proceed. Do I worry about this
differences or concentrate on -gused?
OK, now interesting part. I ran gdb tests with -gused. I expect
more tests to fail because of -gused ussage model. Here is the summary
=== gdb Summary ===
# of expected passes 7016
# of unexpected failures 1468
# of unexpected successes 2
# of expected failures 141
# of known failures 9
# of unresolved testcases 20
# of unsupported tests 1
I am doing analysis of these failures so stay tuned.
-Devang