From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32681 invoked by alias); 30 Nov 2007 23:53:15 -0000 Received: (qmail 32673 invoked by uid 22791); 30 Nov 2007 23:53:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Nov 2007 23:53:07 +0000 Received: (qmail 30582 invoked from network); 30 Nov 2007 23:53:05 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Nov 2007 23:53:05 -0000 To: Thiago Jung Bauermann Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: Keeping breakpoints inserted References: <200711292224.23659.vladimir@codesourcery.com> <1196456622.6746.169.camel@localhost.localdomain> From: Jim Blandy Date: Fri, 30 Nov 2007 23:53:00 -0000 In-Reply-To: <1196456622.6746.169.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Fri, 30 Nov 2007 19:03:42 -0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00305.txt.bz2 Thiago Jung Bauermann writes: > On Thu, 2007-11-29 at 22:24 +0300, Vladimir Prus wrote: >> Anybody has comments on this approach? > > When adding and removing breakpoints, will GDB stop all threads or just > the one under inspection? > > On first thought, I think that if adding a breakpoint can be done > atomically (i.e., trap instruction is 1 word wide), then it wouldn't be > necessary to stop other threads. Am I being too naive here? The Linux kernel has a facility called 'kprobes' (which is extremely cool, BTW) that can insert breakpoint instructions into kernel code while other processors are executing it. This interface has been implemented on many different architectures. We're using it as our model, since it does essentially what we need to do, in an even more challenging context. I haven't seen one where it needs to halt all other processors while inserting the breakpoint. On the i386, you pretty much just save the underlying instruction and drop the trap in. There are processor errata (AH 33 in ftp://download.intel.com/design/mobile/SPECUPDT/31407915.pdf) that warn against the dangers of one processor making changes in another's code stream, but it turns out that the 'int3' instruction --- the one used for breakpoints --- is specifically excluded from those errata; so we're off the hook.