Re: make attaching to stopped processes work under windows

[Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>]

> 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.