From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22601 invoked by alias); 23 Jun 2008 14:41:49 -0000 Received: (qmail 22581 invoked by uid 22791); 23 Jun 2008 14:41:47 -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; Mon, 23 Jun 2008 14:41:30 +0000 Received: (qmail 4953 invoked from network); 23 Jun 2008 14:41:27 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jun 2008 14:41:27 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] win32-nat.c 'set new-console' and interruption Date: Mon, 23 Jun 2008 17:00:00 -0000 User-Agent: KMail/1.9.9 Cc: "Pierre Muller" References: <000001c8d330$0c6b51f0$2541f5d0$@u-strasbg.fr> <20080623114505.GA9244@ednor.casa.cgf.cx> <001001c8d53c$a773fe50$f65bfaf0$@u-strasbg.fr> In-Reply-To: <001001c8d53c$a773fe50$f65bfaf0$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806231541.26276.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2008-06/txt/msg00386.txt.bz2 A Monday 23 June 2008 15:23:06, Pierre Muller wrote: > I have a proposal to remove that possible race condition: > The exception record has a field that contains the exception > address, if I test that there is no GDB inserted breakpoint at > that location before converting the TARGET_SIGNAL_TRAP > into a TARGET_SIGNAL_INT, it should fix most problems, no? > > The one case that it would still not catch would be > a 'int 3' instruction that is in the debuggee code from the start > but other than at startup, such instructions are quite unlikely, no? > IIRC, DebugBreakProcess injects a thread in the debuggee and always breaks at the same address / in the same function -- I don't know if there's a hardcoded 0xcc at the break address you could check, or if the exception is generated programatically, but at least you could conditionalize on the function name (if there's no hardcoded break, you still can't distiguish by name only a user break placed in that special break function) Another option is to use SuspendThread on all threads to stop the process, which is what I believe Visual Studio uses. gdbserver has that implemented for systems that don't have DebugBreakProcess. -- Pedro Alves