From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31402 invoked by alias); 3 Mar 2009 12:05:08 -0000 Received: (qmail 31393 invoked by uid 22791); 3 Mar 2009 12:05:07 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-mx09.nokia.com) (192.100.105.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 12:05:01 +0000 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n23C4OH5009785 for ; Tue, 3 Mar 2009 06:04:57 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 14:04:02 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 14:04:02 +0200 Received: from troll08.nokia.trolltech.de (bett-ws017.europe.nokia.com [172.25.167.41]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with SMTP id n23C40VH014032 for ; Tue, 3 Mar 2009 14:04:01 +0200 Date: Tue, 03 Mar 2009 12:05:00 -0000 From: Oswald Buddenhagen To: gdb-patches@sourceware.org Subject: Re: make attaching to stopped processes work under windows Message-ID: <20090303120504.GA18244@troll08.nokia.trolltech.de> References: <20090302100651.GA8157@troll08.nokia.trolltech.de> <20090302172305.GK26056@adacore.com> <20090302182826.GA11548@troll08.nokia.trolltech.de> <20090226192552.GB15958@troll08.nokia.trolltech.de> <20090228004414.GA21767@ednor.casa.cgf.cx> <20090226192552.GB15958@troll08.nokia.trolltech.de> <20090302195625.GA16983@troll08.nokia.trolltech.de> <20090303052130.GA28801@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090303052130.GA28801@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Nokia-AV: Clean 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: 2009-03/txt/msg00031.txt.bz2 > On Mon, Mar 02, 2009 at 11:21:20PM +0200, Eli Zaretskii wrote: > >Perhaps I read this too naively, but note how you first seem to > >describe a use-case: > > > > This is primarily meant to cover the case where someone > > creates a process in suspended state and hands it over > > to gdb > > > >but then immediately say that it cannot be done: > > > > this is an abstraction - you cannot actually do > > that due to Windows bugs. > > i don't see how this says it cannot be done. it says you can arrive at the desired result only by going through additional hoops. > >After reading this, I already become confused. > > > > You need to start debugging the process yourself, > > and once it has started up, you suspend it and detach from it > > > >And now I'm _really_ confused: ``detach''? didn't you say ``attach'' > >above? why detach from a process if you want to debug it? > > i think the meaning is rather clear when you unnest the sentences properly; the grammar doesn't leave much room for differing interpretations. but i accept your request to use simpler language. ;) On Tue, Mar 03, 2009 at 12:21:30AM -0500, Christopher Faylor wrote: > In my definition of "use case", you don't just theorize that something > could be done, you explain that "Package X does this all of the time > because of Y and that makes it hard for me to debug things." You don't > just assert that you want to change the code because it is theoretically > possible. > well, to me, the idea of being able to attach to a suspended process seems to have enough merit of its own. after all, why should it matter whether the process is suspended in the first place? anyway, i use that to implement a "debug in separate terminal" mode. for that, i launch a stub with controlled process flags. that stub launches the debuggee. for gdb to be able to attach to it without a race, the debuggee needs to be launched in suspended state. once the debuggee ends, the stub prints a "enter to continue" message, waits and terminates. i chose this approach because it is congruent with the xterm + stub approach i use under unix, so it makes the code quite nice. also, it seems less scary than using gdb's somewhat fragile (*) shell hack to start the stub within gdb itself. (*) if i understood anything, this thing must get confused if the debuggee launches child processes itself. > Once the "use case" was explained, I thought I would try to remember > why I had rejected a concept like this in Cygwin many years ago and > see if this was related. I know that I had many problems when I > arbitrarily suspeded processes, especially on older versions of > Windows. > but you realize that attaching *is* suspending, not only logically, but also "physically" (observe the thread suspend count comparison in my patch)? and given my description of the obscure workaround necessary to create an "attachable" suspended process you certainly can imagine that i had my "fun" with "arbitrarily suspended processes". :} i still concluded that this case is "safe". fwiw, given that the "startup hack" works only with WinXP+ (now, you wouldn't expect detaching to be something M$ would implement before 2003, right?), "older" windows versions are not particularly interesting to me anyway.