From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23093 invoked by alias); 23 Jun 2008 16:05:53 -0000 Received: (qmail 23084 invoked by uid 22791); 23 Jun 2008 16:05:52 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 16:05:27 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m5NG5LXn008176 ; Mon, 23 Jun 2008 18:05:21 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m5NG5Lod010850 ; Mon, 23 Jun 2008 18:05:21 +0200 (CEST) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) by mailserver.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id m5NG5HTk077541 ; Mon, 23 Jun 2008 18:05:21 +0200 (CEST) From: "Pierre Muller" To: "'Pedro Alves'" , References: <000001c8d330$0c6b51f0$2541f5d0$@u-strasbg.fr> <20080623114505.GA9244@ednor.casa.cgf.cx> <001001c8d53c$a773fe50$f65bfaf0$@u-strasbg.fr> <200806231541.26276.pedro@codesourcery.com> In-Reply-To: <200806231541.26276.pedro@codesourcery.com> Subject: RE: [RFC] win32-nat.c 'set new-console' and interruption Date: Mon, 23 Jun 2008 17:25:00 -0000 Message-ID: <001601c8d54a$f45a1660$dd0e4320$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::154]); Mon, 23 Jun 2008 18:05:21 +0200 (CEST) X-Virus-Status: Clean 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/msg00387.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Monday, June 23, 2008 4:41 PM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [RFC] win32-nat.c 'set new-console' and interruption >=20 > A Monday 23 June 2008 15:23:06, Pierre Muller wrote: >=20 > > 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? > > >=20 > 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) I checked this: on windows XP it does use an 'int 3' instruction that is situated in ntdll DLL at an exported function named DbgUiConnectToDbg, but I would really like to avoid hard-coding this into win32-nat.c as there is no assurance that other versions of Microsoft OS will use the same 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. That is also a nice idea... The only problem in that case is, which thread do we then use as the current_thread?=20 Do we default on main_thread_id? But the current win32-nat source code has a particularity here: it never removes the main_thread_idd thread even if that thread exits, I don't really know=20 why it was coded like this but that means that using main_thread_id might put us in a 'dead' thread. I never managed to send a patch for this,=20 and I suspect that there are some hidden reason for this strange behavior! We could insert code that stops all threads into win32_wait at the location of the=20 deprecated_ui_loop_hook code, but I don't know really how to handle this: if you suspend manually all threads, you can of course set ourstatus, but the question is how do you coordinate this=20 with the next call to win32_resume? Is it enough to add a global variable threads_suspended_manually (not sure this is the best name) and to add something like if (!threads_suspended_manually) res =3D ContinueDebugEvent (...) else /* Here we add the code to resume all threads */ If fear that we might need more special code, for instance if win32_resume is called with a non zero signal to pass, which would of course be impossible in that case. I would personally prefer to postpone this=20 to a later patch, but Christopher should=20 tell us what the best way is. Pierre Muller Pascal language support maintainer for GDB =20