This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] -gused


On Thu, Jun 19, 2003 at 12:18:08PM -0700, Devang Patel wrote:
> 
> 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?

What version of GDB are you testing?  In CVS, you should not see this
problem; it's a random fluctuation due to the scheduler.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]