From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11778 invoked by alias); 1 Jul 2002 02:44:40 -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 11605 invoked from network); 1 Jul 2002 02:44:35 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 1 Jul 2002 02:44:35 -0000 Received: from gruel-2-175.ppp.andrew.cmu.edu ([128.2.2.175] helo=nevyn.them.org) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17OrAv-0003Yh-00; Sun, 30 Jun 2002 21:44:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17OrAw-0003jN-00; Sun, 30 Jun 2002 22:44:26 -0400 Date: Sun, 30 Jun 2002 19:44:00 -0000 From: Daniel Jacobowitz To: Nathanael Nerode Cc: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: Top Level Autoconfiscation Status Message-ID: <20020701024425.GA14201@nevyn.them.org> Mail-Followup-To: Nathanael Nerode , gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com References: <20020701014139.GA3421@doctormoo.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020701014139.GA3421@doctormoo.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00334.txt.bz2 On Sun, Jun 30, 2002 at 09:41:39PM -0400, Nathanael Nerode wrote: > Take two, no attachments. > > Autoconfiscation? Well, it seems to work. > > This is a long message. Please skip the parts which don't relate to > your area of interest/expertise, and read the other parts. :-) > > Just-GCC native bootstrap on i686-pc-linux-gnu builds. Couldn't 'check' > this one because it's *just* gcc, no dejagnu. > > Ubertree cross-compiler to powerpc-eabisim builds. make check mostly > works; unexpected failures are below. > > * zlib has no check target, so I have to somehow leave it out > * mmalloc doesn't check properly (it has an entirely defective rule), so > I have to leave it out. This is probably because of a bug in the old > Makefile which prevented mmalloc from being checked by 'make check' -- > it's a substitution error, 'check-mmcheckoc' for 'check-mmalloc'. > > binutils has one unexpected failure > ----------------------------------- > * 'readelf -wi'. > I doubt that this is due to my changes, though verification would be > nice. > > gdb has quite a lot of unexpected failures: > ------------------------------------------- > * gdb.base/call-rt-st.exp: print print_five_chats(*five_char)' > * gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2) > * gdb.base/callfuncs.exp: call inferior func with struct -- returns > float > * gdb.base/callfuncs.exp: backtrace at nested call level 2 > * gdb.base/callfuncs.exp: backtrace at nested call level 3 > * gdb.base/callfuncs.exp: backtrace at nested call level 4 > * gdb.base/callfuncs.exp: backtrace after finish from nested call level 4 > * gdb.base/callfuncs.exp: backtrace after finish from nested call level 3 > * gdb.base/commands.exp: continue with watch > * gdb.base/ending-run.exp: step out of main (at end 2) > * gdb.base/finish.exp: finish from float_func > * gdb.base/funcargs.exp: print *stp > * gdb.base/printcmds.exp: ptype &*"foo" > * gdb.base/recurse.exp: second instance watchpoint deleted when leaving > scope > * gdb.base/recurse.exp: continue to first instance watchpoint, second > time > * gdb.base/recurse.exp: first instance watchpoint deleted when leaving > scope > * gdb.base/relocate.exp: static variables have different addresses > * gdb.base/return2.exp: char value returned successrully > * gdb.base/return2.exp: short value returned successrully > * gdb.base/return2.exp: float value returned successrully > * gdb.base/structs.exp: p fun5() > * gdb.base/structs.exp: p fun6() > * gdb.base/structs.exp: p fun7() > * gdb.c++/cplusfuncs.exp: print &'hairyfunc5' > * gdb.c++/cplusfuncs.exp: print &'hairyfunc6' > * gdb.c++/cplusfuncs.exp: print &'hairyfunc7' > * gdb.c++/local.exp: ptype Local (gdb/483) > * gdb.c++/local.exp: ptype InnerLocal::NestedInnerLocal (gdb/482) > * gdb.c++/ovldbreak.exp: continue to bp overloaded : int > * gdb.c++/ovldbreak.exp: continue to bp overloaded : (unsigned|unsigned > int) > * gdb.c++/ovldbreak.exp: continue to bp overloaded : long > * gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned long > * gdb.c++/templates.exp: ptype T5 > * gdb.c++/templates.exp: ptype t5i > * gdb.c++/templates.exp: constructor breakpoint (bad menu choices) > * gdb.c++/templates.exp: destructor breakpoint > * gdb.c++/templates.exp: print Foo::foo > * gdb.c++/templates.exp: print Garply >::garply > * gdb.mi/mi-console.exp: Hello message (known bug) > * gdb.mi/mi-stack.exp: stack args listing 0 > * gdb.mi/mi-stack.exp: stack args listing 1 > * gdb.mi/mi-var-child.exp: get number of children of > struct_declarations.s2.u2.u1s1 > * gdb.mi/mi-var-child.exp: create local variable weird > * gdb.mi/mi-var-cmd.exp: update all vars: all now out of scope > * gdb.mi/mi-var-cmd.exp: delete var > * gdb.mi/mi-var-display.exp: create local variable weird > * gdb.mi/mi-var-display.exp: get children local variable weird > * gdb.mi/mi-watch.exp: wp out of scope (2) > * gdb.mi/mi0-console.exp: Hello message (known bug) > * gdb.mi/mi0-stack.exp: stack args listing 0 > * gdb.mi/mi0-stack.exp: stack args listing 1 > * gdb.mi/mi0-var-child.exp: get children of > struct_declarations.s2.u2.u1s1 > * gdb.mi/mi0-var-child.exp: create local variable weird > * gdb.mi/mi0-var-cmd.exp: update all vars: all now out of scope > * gdb.mi/mi0-var-cmd.exp: delete var > * gdb.mi/mi0-var-display.exp: create local variable weird > * gdb.mi/mi0-var-display.exp: get children local variable weird > * gdb.mi/mi0-watch.exp: wp out of scope (2) > > I need to figure out if any of these are my fault and if so where to > look for the source of the problems; I don't have any clue where to > look. I'm actually wondering if some of these are spurious, since > subsequent tests which sound like they should be dependent, succeed. :-P > It also looks suspiciously like there are some duplicate tests in here. > I'm also wondering how many of these tests are expected to work in a > cross environment. :-P Most work cross if you have a simulator. Above is just about the standard test results for GDB; it's always a little messy. > gcc has few unexpected failures > ------------------------------- > * gcc.c-torture/compile/20001226-1.c, -O3 -g > Timed out, so I don't think it has anything to do with my changes. That's the DBR timeout if I remember correctly; don't worry about it. > *except* that I would like the autoconfiscation to go into mainline of > gcc and of src at the same time. I'm not sure what the best strategy to > try to achieve that is, given the different schedules and processes of > gcc, binutils, and gdb. As long as it doesn't happen in the next week or so; binutils has a branch coming up in early July. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer