From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9461 invoked by alias); 1 Jul 2002 01:43:31 -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 9436 invoked from network); 1 Jul 2002 01:43:26 -0000 Received: from unknown (HELO nerodeguest) (24.161.107.98) by sources.redhat.com with SMTP; 1 Jul 2002 01:43:26 -0000 Received: from neroden by nerodeguest with local (Exim 3.35 #1 (Debian)) id 17OqCB-0000tm-00; Sun, 30 Jun 2002 21:41:39 -0400 Date: Sun, 30 Jun 2002 18:43:00 -0000 To: gcc@gcc.gnu.org, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Top Level Autoconfiscation Status Message-ID: <20020701014139.GA3421@doctormoo.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Nathanael Nerode X-SW-Source: 2002-06/txt/msg00332.txt.bz2 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 sid has some unexpected failures: --------------------------------- * assert tx * deassert tx (apparently related to trying to open /dev/audio) * read identification for drive 0 - wait 06 0x08 0x08 - unmapped 0 * read identification for drive 0 * read identification for nonexistent drive 1 - wait 06 0x01 0x01 - unmapped 0 * read identification for nonexistent drive 1 * write first sector of drive 0 - wait 06 0x08 0x08 - unmapped 0 * write first sector of drive 0 - wait 06 0x01 0x00 - unmapped 0 * write first sector of drive 0 * write second sector of drive 0 using shorts - wait 06 0x08 0x08 - unmapped 0 * write second sector of drive 0 using shorts - wait 06 0x01 0x00 - unmapped 0 * write second sector of drive 0 using shorts * copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1 - wait 06 0x08 0x08 - unmapped 0 * copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1 - wait 06 0x01 0x00 - unmapped 0 (the last two appear four times each!) * copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1 * acquire mapper bus handle * set memory state dump * reread junk from memory after restore - mismatch @3 - 192 vs 0 * reread junk from memory after restore * reload sparse (RLE) snapshot * save & restore large memory snapshot - ok bad_value I don't even know what these mean, but I still doubt they have anything to do with me. 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. * Some other tests fail which were already failing according to geoff's regression tester. libstdc++-v3 has few unexpected failures ---------------------------------------- * 26_numerics/c99_classification_macros_c.cc (test for excess errors) I don't see how this could have anything to do with me. * Some other tests fail which were already failing according to geoff's regression tester. newlib has some unexpected failures ----------------------------------- * Failed to compile UTF-8.c * Failed to compile atexit.c * Failed to compile /home/neroden/gnu/both_auto/newlib/testsuite/newlib.string/tstring.c * /home/neroden/gnu/both_auto/newlib/testsuite/newlib.string/tstring.c Same errors showed up in the alternate newlib subdirs "und","le","ca","le/und","nof","nof/und","nof/ca","nof/le","nof/le/und", whatever the heck those are. Again, I doubt this has anything to do with me. --------------------- I'm going to do an ubertree native build & check as soon as I free up enough space on my hard drive. :-P This is not a fun test platform, since it's slow and has fairly limited test space. I'm wondering what the correct thing to do next is. Obviously a *lot* more configurations should be tested. I only have one hardware configuration, so I'm not really sure how to test the build!=host ones. I'm also getting kind of burned out on testing; getting other people to test their favorite configurations would certainly help, even if they are configurations I could test. There are also other things to test (I might possibly have broken weird targets like taz and gcc-no-fixincludes). I don't know if there's any chance of this getting into mainline for gcc 3.2; it is a large change, although it affects very few files and I think it's quite stable. I have no objections to aiming for 3.3 phase 1... *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. Should I start a branch? I have various worries about doing that for this particular project, which I may have stated elsewhere. Advantages of the autoconfiscation: ---------------------------------- * Nearly all the 'make' logic is in dependencies, not embedded rules. This makes 'make' faster, particularly on incremental builds. It also helps avoid certain types of bugs. * Repetitive makefile targets are autogenerated, avoiding nasty typos (do a grep on the old Makefile for 'check-mmcheckoc' to see what I mean), and making changes significantly simpler. * All subconfigures are invoked from the Makefile rather than directly from top level configure. This has certain debugging advantages. * ~55K less code to maintain manually. * No more Cygnus configure. Potential disadvantages: ------------------------ * To avoid a lot of subtle problems, configure uses absolute pathnames for most directories which it puts into the Makefile. This means you can no longer 'configure', relocate srcdir or builddir, and then 'make'. I doubt that this is important. * I'm sure there's more I can do to clean it up. I'd rather do that after tackling some other cleanup projects though. I'll try to submit the files involved sometime; they're kinda large. --Nathanael