This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB Ctrl-C Interrupt Fails WORKAROUND


On Thu, 15 Jun 2006, Kyle McKay wrote:

> On 15 Jun 2006 at 00:44:05 -0400 Christopher Faylor wrote:
> > On Wed, Jun 14, 2006 at 08:29:50PM -0700, Kyle McKay wrote:
> > > If you have ever tried to interrupt a program running under cygwin
> > > gdb, you have probably experienced some frustration.  Especially if
> > > the program was built with -mno-cygwin.
> >
> > No I never have.  In fact I often rely on CTRL-C interrupting the
> > program.  It doesn't matter whether the program is built with
> > -mno-cygwin or not.  In fact, I am sometimes frustrated when I actually
> > want the CTRL-C to be propagated to the program but then I remember
> > about the "handle" command.
> >
> > The only time that I can think of when a CTRL-C would not interrupt a
> > program would be when you're running gdb under a cygwin pty or tty.  But
> > it's usually easy enough not to do that if you are debugging a problem.
>
> I'm happy for you that CTRL-C works for you.  It does not work for me.
>
> I'm almost never running gdb from a genuine DOS command prompt.
> Sometimes via ssh, sometimes via a terminal emulator.  CTRL-C doesn't
> work in those.
>
> Also, if you have "tty" in your CYGWIN variable it doesn't work even
> from a DOS command prompt.

That's what CGF said.

> Finally, it NEVER works no matter what if you are debugging a program
> built with a different compiler such as m$ visual C++.  And, of course,
> you say I have no reason to do that since the debugging symbols will not
> be compatible. However, the m$ visual C++ built program is then loading
> a cygwin/mingw built DLL.  CTRL-C doesn't work in this case to interrupt
> the running program. Although if you are careful you can get breakpoints
> set, but if you change your mind after you start running the program
> again then you're out of luck. That's where the debugbreak utility comes
> in very handy.

Does "kill -INT <cygwin_pid>" work?

> Lacking the ability to interrupt a running program severely limits gdb's
> usefulness.  Fortunately there's a workaround available.

The workaround would be even better if you didn't need a separate program.
How about submitting a patch for Cygwin's "kill" (with a new signal,
SIGDBG or SIGDEBUG)?  CGF, would you consider such a patch?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]