From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11589 invoked by alias); 23 Oct 2007 16:46:34 -0000 Received: (qmail 11576 invoked by uid 22791); 23 Oct 2007 16:46:34 -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; Tue, 23 Oct 2007 16:46:31 +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 1IkMtf-0004vh-00; Tue, 23 Oct 2007 17:46:27 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IkMtY-00009m-00; Tue, 23 Oct 2007 17:46:20 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IkMtY-00025Y-IM; Tue, 23 Oct 2007 17:46:20 +0100 Date: Tue, 23 Oct 2007 17:10:00 -0000 From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" , Mark Kettenis Subject: Re: hbreak.exp: Test hardware breakpoints In-Reply-To: <20070930011752.GA21283@caradoc.them.org> Message-ID: References: <20070921230133.GB28500@caradoc.them.org> <20070924113241.GA7618@caradoc.them.org> <20070930011752.GA21283@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-10/txt/msg00542.txt.bz2 On Sat, 29 Sep 2007, Daniel Jacobowitz wrote: > Maciej posted a patch to test hardware breakpoints. It passes on > i386-linux, using current HEAD GDB. I wanted to see what would happen > when the test was run against gdbserver, which does not support > hardware breakpoints on i386 (yet). We encountered the long-standing > bug that nm-i386.h overrides target.h using #define; this means that > a native i386 GDB incorrectly tries to use ptrace even when connected > to a remote target. > > I saw two ways to test: build a cross debugger or fix the bug. I > fixed the bug. Unfortunately that broke the test: > > (gdb) hbreak main > No hardware breakpoint support in the target. > UNSUPPORTED: gdb.base/hbreak.exp: hardware breakpoints > > This is "target exec", since we have not yet started the program. > While we were using #define to override GDB's defaults, this worked; > every target, even exec, claimed to support watchpoints. Now that > only "target child" supports hardware watchpoints, you can't insert > hardware breakpoints before the program is running. > > This is the status quo on other targets too. > > How do you all feel about leaving the hbreak-before-run problem for > another day, and adjusting the test to start the program running > before trying hbreak? Have we reached any conclusion on this matter? I cannot seem to find any... I am certainly fine to adjust the test script, at least for now -- no problem. The question is how problematic, if at all, the change is to people in actual debugging. For example, how often is a hardware breakpoint used locally before a program is started: (gdb) hbreak foo (gdb) run How about: (gdb) break main (gdb) run [main() hit] (gdb) hbreak foo (gdb) continue [foo() hit] (gdb) run And similarly for remote targets -- presumably having to define a breakpoint before a connection is opened to the target is a non-issue, but how about: (gdb) target bar (gdb) load (gdb) hbreak foo (gdb) run [foo() hit] (gdb) target bar Not that these cases bother me terribly much, but they should be noted and dismissed if not important enough. Maciej