From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21031 invoked by alias); 9 Oct 2008 11:37:14 -0000 Received: (qmail 20772 invoked by uid 22791); 9 Oct 2008 11:37:13 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 09 Oct 2008 11:36:33 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m99BaTeH052492 for ; Thu, 9 Oct 2008 13:36:29 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m99BaTXC017056 for ; Thu, 9 Oct 2008 13:36:29 +0200 (CEST) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id m99BaTLd048350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 9 Oct 2008 13:36:29 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: Subject: Results of macscp.exp test on cygwin Date: Thu, 09 Oct 2008 11:37:00 -0000 Message-ID: <011801c92a03$4b71afa0$e2550ee0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::153]); Thu, 09 Oct 2008 13:36:29 +0200 (CEST) X-Virus-Status: Clean Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00282.txt.bz2 Following a recent email about the testsuite that I ran on cygwin, where Pedro fond that the number of failures was very high, I started to look into this. Cygwin target uses stabs debugging format as a default, but stabs doesn't generate any macro debugging information, which results in 244 FAIL's (87 KFAIL plus 157 FAIL) from this unique test. Shouldn't we force dwarf-2 debug format, or at least skip the test if only stabs format is available? The test just add "-g3" option to the compilation command line and that does not switch over to dwarf-2 debugging format. Using make check RUNTESTFLAGS="gdb.base/macscp.exp CC_FOR_TARGET=\"gcc -gstabs+\"" I get 67 PASS, 87 KFAIL and 157 FAIL. The strange thing is that even with make check RUNTESTFLAGS="gdb.base/macscp.exp CC_FOR_TARGET=\"gcc -gdwarf-2\"" (gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)) I still get the same results :( Only if I force the use of gcc version 4 (gcc version 4.3.2 20080827 (alpha-testing) 1 (GCC)) make check RUNTESTFLAGS="gdb.base/macscp.exp CC_FOR_TARGET=\"gcc-4 -gdwarf-2\"" do I get good results: PASSES: 286 FAIL:6 KFAIL:19 FAIL: gdb.base/macscp.exp: c99 varargs expansion FAIL: gdb.base/macscp.exp: c99 varargs expansion without an argument FAIL: gdb.base/macscp.exp: c99 varargs expansion, multiple formal arguments FAIL: gdb.base/macscp.exp: gnu varargs expansion FAIL: gdb.base/macscp.exp: gnu varargs expansion without an argument FAIL: gdb.base/macscp.exp: gnu varargs expansion special splicing without an argument These failures are all due to the fact that stderr is itself a macro in cygwin that is expanded into "((__getreent())->_stderr)". I also checked that gcc-4 with stabs, and I also get the 87 KFAIL and 157 FAIL. So all these tests seem to require gcc version 4, and explicit dwarf-2 selection. Is gcc version 3 still being developed? If not, we could probably just fail generally once and skip the whole rest of the test if gcc version 3 is used. Should we add something to force use of 'dwarf-2' debug format? Or at least also fail only once if stabs is used and skip the rest? Pierre Muller Pascal language support maintainer for GDB