From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2930 invoked by alias); 12 May 2003 21:23:17 -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 2671 invoked from network); 12 May 2003 21:23:13 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 12 May 2003 21:23:13 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19FKla-0004tg-00; Mon, 12 May 2003 16:23:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19FKl7-0001xQ-00; Mon, 12 May 2003 17:22:57 -0400 Date: Mon, 12 May 2003 21:23:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: Andrew Cagney , "H. J. Lu" , "J. Johnston" , Elena Zannoni , GDB Subject: Re: NPTL thread support Message-ID: <20030512212257.GA6664@nevyn.them.org> Mail-Followup-To: David Carlton , Andrew Cagney , "H. J. Lu" , "J. Johnston" , Elena Zannoni , GDB References: <20030509075610.B1675@lucon.org> <16059.52718.465177.555337@localhost.redhat.com> <20030509091522.A2960@lucon.org> <16059.55278.841645.134311@localhost.redhat.com> <20030511134556.A22269@lucon.org> <3EBFF3ED.8050807@redhat.com> <20030512130839.A9491@lucon.org> <3EC00D8C.1040100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00213.txt.bz2 On Mon, May 12, 2003 at 02:18:30PM -0700, David Carlton wrote: > On Mon, 12 May 2003 17:09:32 -0400, Andrew Cagney said: > > >> These are all normal. (I can't speak about the gdb.objc ones.) > > > Unless you've got ObjC installed, those are normal as well (it > > should probably be tweaked too, like threads, just fail when the > > compiler dies). > > Whoops, you're right: I thought I was seeing different messages, but I > was seeing those FAILs as well. I agree that the current failure mode > for gdb.objc is suboptimal. Though calling gdb_suppress_entire_file > sounds reasonable to me; is there no way to fix it to actually end the > file instead of trying and failing to suppress the tests in the file? Just say "return 0"? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer