From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27754 invoked by alias); 25 Nov 2003 04:44:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27742 invoked from network); 25 Nov 2003 04:44:35 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sources.redhat.com with SMTP; 25 Nov 2003 04:44:35 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AOV3w-0002Qw-00; Mon, 24 Nov 2003 23:44:32 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 1D0E84B409; Mon, 24 Nov 2003 23:44:26 -0500 (EST) To: carlton@kealia.com, ian@wasabisystems.com Subject: Re: C++/Java regressions Cc: gdb@sources.redhat.com Message-Id: <20031125044426.1D0E84B409@berman.michael-chastain.com> Date: Tue, 25 Nov 2003 04:44:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-11/txt/msg00235.txt.bz2 Hi Ian and David, My last spin was with gdb HEAD checked out on 2003-11-21 06:25:07. I got some new demangler code, because my gdb HEAD had "715 tests, 18 failures" instead of the old "715 tests, 31 failures". However I did not get the "cp-demangle.c: complete rewrite" version. I didn't see any demangler-related changes in my results. I'll fire up some scripts and see if I can see any difference now. ian> I'm not saying that the problem is not the demangler. I don't know ian> what the problem is. If you can give more information, I would be ian> happy to adjust the demangler. Totally reasonable. For what it's worth, how would I file a demangler bug report? Do I just file it in gcc bugzilla, because the primary copy of libiberty lives in gcc? ian> I enclose the diff of gdb.sum. Cool! Just because I'm such a gdb test suite geek, I'll post a little analysis of what you are seeing. I'd like to keep improving the test suite so that "diff gdb-1.sum gdb-2.sum" has less noise in it. It has been getting better lately. Michael C -PASS: gdb.base/pc-fp.exp: get value of $fp (0xbfffe788) +PASS: gdb.base/pc-fp.exp: get value of $fp (0xbfffe388) The test name has a machine address in it, so it fluctuates a bit from run to run (obviously). -PASS: gdb.cp/cplusfuncs.exp: print &'overload1arg(unsigned)' +PASS: gdb.cp/cplusfuncs.exp: print &'overload1arg(unsigned int)' You changed the demangler. -KFAIL: gdb.cp/cplusfuncs.exp: print &'hairyfunc5' (PRMS: gdb/19) -KFAIL: gdb.cp/cplusfuncs.exp: print &'hairyfunc6' (PRMS: gdb/19) -KFAIL: gdb.cp/cplusfuncs.exp: print &'hairyfunc7' (PRMS: gdb/19) +PASS: gdb.cp/cplusfuncs.exp: print &'hairyfunc5' +PASS: gdb.cp/cplusfuncs.exp: print &'hairyfunc6' +PASS: gdb.cp/cplusfuncs.exp: print &'hairyfunc7' You fixed a bug in the demangler (a very old bug, gdb/19). Cool! -PASS: gdb.threads/print-threads.exp: Hit kill breakpoint, 9 (slow with kill breakpoint) PASS: gdb.threads/print-threads.exp: Hit thread_function breakpoint, 4 (slow with kill breakpoint) +PASS: gdb.threads/print-threads.exp: Hit kill breakpoint, 9 (slow with kill breakpoint) Non-determinism in the order of execution of thread tests. -PASS: gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint) PASS: gdb.threads/print-threads.exp: Hit kill breakpoint, 11 (slow with kill breakpoint) +PASS: gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint) Ditto. -PASS: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2 -PASS: gdb.threads/pthreads.exp: backtrace from thread 2 bkpt in common_routine +FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2 My understanding is that this is a real race condition between gdb and the operating system. It happens about one time every 500 or so test runs for me. Daniel J knows more about this. Whatever it is, it's not a demangler problem. -PASS: gdb.threads/schedlock.exp: other thread 2 didn't run -PASS: gdb.threads/schedlock.exp: other thread 3 didn't run PASS: gdb.threads/schedlock.exp: current thread ran +PASS: gdb.threads/schedlock.exp: other thread 3 didn't run +PASS: gdb.threads/schedlock.exp: other thread 4 didn't run More thread non-determinism, sigh. As long as they all pass it's okay.