From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25604 invoked by alias); 30 Jul 2004 00:55:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25586 invoked from network); 30 Jul 2004 00:55:54 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sourceware.org with SMTP; 30 Jul 2004 00:55:54 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BqLgP-0004QS-00; Thu, 29 Jul 2004 20:55:38 -0400 Received: from mindspring.com (localhost [127.0.0.1]) by berman.michael-chastain.com (Postfix) with SMTP id C5BAD4B102; Thu, 29 Jul 2004 20:55:54 -0400 (EDT) Date: Fri, 30 Jul 2004 00:55:00 -0000 From: Michael Chastain To: kettenis@chello.nl, drow@false.org Subject: Re: [RFA]: threaded watchpoint test Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com Message-ID: <41099C99.nail5DO11TT76@mindspring.com> References: <4106A553.7010202@redhat.com> <20040727230053.GA31203@nevyn.them.org> <4106E42F.3010304@redhat.com> <20040727232634.GA32379@nevyn.them.org> <4106EF7A.nail46S11RRBB@mindspring.com> <20040729152517.GA7192@nevyn.them.org> <200407292338.i6TNcNNY024581@elgar.kettenis.dyndns.org> In-Reply-To: <200407292338.i6TNcNNY024581@elgar.kettenis.dyndns.org> User-Agent: nail 10.8 6/28/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00483.txt.bz2 Mark Kettenis writes: mark> Why do we allow tests like this to be checked in if we know they mark> produce massive fails on many systems? To take the philosophical question first: there's no registry of which systems are actually tested with gdb. The list of posts to gdb-testers@ is the only thing I have. If a system is not represented there then I pay less attention to it. Hmmm, this is in gdb.threads, I should not even have approved this patch in the first place! I apologize to Michael Snyder. mark> Hmm, I'm getting a bit frustrated that folks keep adding things to the mark> testsuite that assume features that are not available on most things mark> not i386 GNU/Linux. I hear you. Daniel Jacobowitz writes: drow> Maybe not. It could be a bug to get a software watchpoint when we drow> expect a hardware one. The question is whether we want to keep a drow> separate list of "do we expect hardware watchpoints" in the testsuite. I think so, but I'm not sure. Two possible approaches are: (1) The test suite does not keep its own info. The test suite asks gdb whether gdb supports feature X, and trusts gdb. (2) The test suite keeps separate info. That way, the test suite is actually testing gdb, not just asking and trusting it. But the info can get out of sync. (2A) A whitelist of systems to test. (2B) A blacklist of systems not to test. I'm inclined to some form of (2). I don't like (1) because the test suite is supposed to *test* gdb, not just trust gdb's answers. Also, I don't know any existing gdb command to ask this question. On the other hand, hardware watchpoints are not meant to work on all systems, so it might be reasonable to ask gdb about them. gdb.base/bigcore.exp is a big test that uses (2). First it blacklists all the !isnative systems. Then it blacklists four specific systems: bsd, hpux, solaris, cygwin. For hardware watchpoint tests, the blacklist would be pretty long. That's okay with me, it's just painful to set up the first time. What do y'all think? Michael C