From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6622 invoked by alias); 24 Sep 2007 11:23:44 -0000 Received: (qmail 6612 invoked by uid 22791); 24 Sep 2007 11:23:43 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Sep 2007 11:23:41 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IZm2K-0008TM-00; Mon, 24 Sep 2007 12:23:36 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IZm2D-0002zw-00; Mon, 24 Sep 2007 12:23:29 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IZm2D-0004iX-3e; Mon, 24 Sep 2007 12:23:29 +0100 Date: Mon, 24 Sep 2007 11:23:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: hbreak.exp: Test hardware breakpoints In-Reply-To: <20070921230133.GB28500@caradoc.them.org> Message-ID: References: <20070921230133.GB28500@caradoc.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00337.txt.bz2 On Fri, 21 Sep 2007, Daniel Jacobowitz wrote: > > 2007-09-12 Maciej W. Rozycki > > > > * gdb.base/hbreak.exp: New test for "hbreak" and "thbreak". > > > > OK to apply? > > No, sorry. Compare this to the current break.exp - you'll see > that it has some cruft that was cleaned out of that testcase, like > gdb_suppress_entire_file. That's doable -- I have missed these changes were done somehow, sorry. I will apply them and resubmit. > Also, when I try it using gdbserver it fails a lot of tests. This > is at least partially related to the previous problem (gdb_run_cmd > was added). I wanted to see what happened on a target that only > failed to insert hardware breakpoints at continue. I do not have such a target, so I do not have means to test. Conservatively, I used one breakpoint only, so it should not normally happen as there will be at most a single such breakpoint enabled at any given time. If there is a target for which it is not enough of an assumption indeed, I can see what can be done, though the maintainer of the target is welcome to provide some support with that. I have a MIPS target down the queue for which I have not submitted support yet, using EJTAG, but with that the smallest number of hardware breakpoints I have encountered in a given CPU was eight (and the i386 in its regular mode of operation has four). It was this target I created this test script in the first place and, as you may expect, it passes all the tests included (though changes to gdb itself were required; these are pending too). Maciej