Re: [PATCH] -gused

[Devang Patel <dpatel at apple dot com>]

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