From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13167 invoked by alias); 25 Mar 2003 16:55:36 -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 13146 invoked from network); 25 Mar 2003 16:55:35 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 25 Mar 2003 16:55:35 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18xtbV-0006zT-00; Tue, 25 Mar 2003 12:56:57 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18xrhx-0004NX-00; Tue, 25 Mar 2003 11:55:29 -0500 Date: Tue, 25 Mar 2003 16:55:00 -0000 From: Daniel Jacobowitz To: Richard.Earnshaw@arm.com Cc: gdb@sources.redhat.com Subject: Re: A brief analysis of the arm-elf failures for gdb Message-ID: <20030325165528.GA16762@nevyn.them.org> Mail-Followup-To: Richard.Earnshaw@arm.com, gdb@sources.redhat.com References: <200303251647.h2PGlxx13963@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303251647.h2PGlxx13963@pc960.cambridge.arm.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00343.txt.bz2 On Tue, Mar 25, 2003 at 04:47:58PM +0000, Richard Earnshaw wrote: > Running the gdb testsuite on an arm-elf configuration and with current gcc > shows just 20 failures. I've done a brief analysis of these below, it > appears that most of the problems are related to the testsuite itself, > rather than gdb. > > FAIL: gdb.base/args.exp: correct args printed > FAIL: gdb.base/args.exp: correct args printed, one empty > FAIL: gdb.base/args.exp: correct args printed, two empty > > These tests fail on a simulator because the framework omits the steps > (gdb) target sim > (gdb) load > before trying to run the program. > > FAIL: gdb.base/huge.exp: print a very large data object > > This loads an application over the stack space. Consequently, when it > runs the data area is clobbered by stack writes and we fail to get the > desired output. Is there an easy way to disable this test? Yes. Try set_board_info gdb,skip_huge_test 1. > FAIL: gdb.base/ptype.exp: ptype t_char_array > FAIL: gdb.base/ptype.exp: ptype func_type > > Neither of the above types are emitted in dwarf2 debug formats by gcc if > they are not used. We need some data object with that type to make this > test useful. Definitely a test bug. > FAIL: gdb.base/store.exp: next field 1 > FAIL: gdb.base/store.exp: next field 2 > FAIL: gdb.base/store.exp: next field 3 > FAIL: gdb.base/store.exp: next field 4 > > The debugger is stopping on the line after the return statement (the > closing brace for the function). If this is a bug at all, then it is most > likely in gcc. That's quite possible. Should be investigated eventually. > FAIL: gdb.c++/anon-union.exp: print w 1 > FAIL: gdb.c++/anon-union.exp: print z 1 > FAIL: gdb.c++/anon-union.exp: print w 2 > FAIL: gdb.c++/anon-union.exp: print z 2 > FAIL: gdb.c++/anon-union.exp: print w 3 > FAIL: gdb.c++/anon-union.exp: print z 3 > > Not sure what these are (c++). Don't know. Until a few weeks ago when Jason fixed it, GCC couldn't even compile this test. > > FAIL: gdb.c++/templates.exp: ptype T5 > FAIL: gdb.c++/templates.exp: ptype t5i > > The information appears to differ only in white space from the "new with > unsigned int" pattern. The pattern expects func( and gdb is > emitting func(. I think David Carlton had a patch for this? > FAIL: gdb.mi/mi-var-display.exp: get children local variable weird > FAIL: gdb.mi/mi1-var-display.exp: get children local variable weird > > Don't know about these two. These fail everywhere with GCC 3.x, someone should look into it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer