sending CTRL-C to Cygwin gdb 6.8 has no effect

sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

In CDT, we've had to resort to sending a CTRL-C to the inferior 
process of a Cygwin gdb session because gdb itself doesn't react to 
the CTRL-C. Is this a known issue? Is it addressed in HEAD? 
Naturally, that approach isn't an option when debugging a remote program.

John

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Joel Brobecker]

> In CDT, we've had to resort to sending a CTRL-C to the inferior
> process of a Cygwin gdb session because gdb itself doesn't react to
> the CTRL-C. Is this a known issue? Is it addressed in HEAD?

This should have been fixed in recent versions of GDB. I don't remember
which version first started having the fix, but it's a safe bet that 7.1
will.

> Naturally, that approach isn't an option when debugging a remote
> program.

But when you are doing remote debugging, the transport protocol used
between GDB and the target should provide a way to send that interrupt.
For instance, when using the remote protocol:

    http://www.sourceware.org/gdb/current/onlinedocs/gdb/Interrupts.html#Interrupts

-- 
Joel

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

At 02:44 PM 4/23/2010, Joel Brobecker wrote:
> > In CDT, we've had to resort to sending a CTRL-C to the inferior
> > process of a Cygwin gdb session because gdb itself doesn't react to
> > the CTRL-C. Is this a known issue? Is it addressed in HEAD?
>
>This should have been fixed in recent versions of GDB. I don't remember
>which version first started having the fix, but it's a safe bet that 7.1
>will.

It for sure isn't present in MinGW 7.0 gdb, but then again, the 
problem is also not in their 6.8 version (not that it works well, 
btw, but it does interrupt it). As Cygwin gdb 7.0 isn't available 
other than in source form (and I don't have the cycles or motivation 
to build it from source), I figured I'd ask the list.


> > Naturally, that approach isn't an option when debugging a remote
> > program.
>
>But when you are doing remote debugging, the transport protocol used
>between GDB and the target should provide a way to send that interrupt.
>For instance, when using the remote protocol:
>
> 
>http://www.sourceware.org/gdb/current/onlinedocs/gdb/Interrupts.html#Interrupts

Hm. That document tells me that gdb itself can interrupt a remote 
inferior, but how do I tell gdb to do so? I'm not a gdb expert, so 
perhaps this is a dumb question. 

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Joel Brobecker]

This is as much as I know without having to look deeper into this,
but that should give you enough info to figure out the rest...

The change that improved the control-c behavior is the following one:

| 2009-03-22   Nicolas Roche  <roche@adacore.com>
|              Christopher Faylor <me+cygwin@cgf.cx>
| 
|         * win32-nat.c (ctrl_c_handler): New function.
|         (win32_wait): Register ctrl_c_handler as Ctrl-C handler if the inferior
|         is run in a separate console.

> Hm. That document tells me that gdb itself can interrupt a remote
> inferior, but how do I tell gdb to do so? I'm not a gdb expert, so
> perhaps this is a dumb question.

It depends of your environement, but basically, you press ctrl-c, or
you get the IDE to send this ctrl-c to GDB.

-- 
Joel

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

At 03:11 PM 4/23/2010, Joel Brobecker wrote:
>This is as much as I know without having to look deeper into this,
>but that should give you enough info to figure out the rest...
>
>The change that improved the control-c behavior is the following one:
>
>| 2009-03-22   Nicolas Roche  <roche@adacore.com>
>|              Christopher Faylor <me+cygwin@cgf.cx>
>|
>|         * win32-nat.c (ctrl_c_handler): New function.
>|         (win32_wait): Register ctrl_c_handler as Ctrl-C handler if 
>the inferior
>|         is run in a separate console.
>
> > Hm. That document tells me that gdb itself can interrupt a remote
> > inferior, but how do I tell gdb to do so? I'm not a gdb expert, so
> > perhaps this is a dumb question.
>
>It depends of your environement, but basically, you press ctrl-c, or
>you get the IDE to send this ctrl-c to GDB.

Ah, OK so I assume you're saying the ability to interrupt a remote 
inferrior is in HEAD and not 6.8. Since sending CTRL-C to cygwin gdb 
6.8 is doing nothing for us when the inferior is local. I assume it 
would also do nothing for us if the inferior is remote.

So, my point is that with cygwin gdb 6.8, CDT has to send the CTRL-C 
to the local inferior in order to interrupt the program, since 
sending it to gdb has no effect. I was looking for confirmation that 
it's a known issue (and not something wrong we're doing). But as I 
say that, it occurs to me...why isn't the issue reproducible at the 
cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb 
session successfully interrupts the target program, why is sending 
the CTRL-C programatically not working? Any thoughts there?

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Pedro Alves]

On Friday 23 April 2010 21:25:10, John Cortell wrote:
> cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb 
> session successfully interrupts the target program, why is sending 
> the CTRL-C programatically not working? Any thoughts there?

In the latter case, is GDB sharing a console with the inferior?
If not sharing a console (native debugging, that is), newer GDB's
that postdate that patch Joel pointed you at, will catch the
CTRL_C_EVENT themselves, and still try to interrupt the inferior
with DebugBreakProcess.  Older GDB's, like 6.8, do nothing.

With remote debugging, I think sending a ctrl-c to
GDB should work, even in 6.8 (provided there's a console
and GDB does get the CTRL_C_EVENT, or if this is a cygwin gdb,
you sent it a real SIGINT signal).  Did you try it?

-- 
Pedro Alves

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

At 08:09 PM 4/23/2010, Pedro Alves wrote:
>On Friday 23 April 2010 21:25:10, John Cortell wrote:
> > cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb
> > session successfully interrupts the target program, why is sending
> > the CTRL-C programatically not working? Any thoughts there?
>
>In the latter case, is GDB sharing a console with the inferior?
>If not sharing a console (native debugging, that is), newer GDB's
>that postdate that patch Joel pointed you at, will catch the
>CTRL_C_EVENT themselves, and still try to interrupt the inferior
>with DebugBreakProcess.  Older GDB's, like 6.8, do nothing.

I'm not sure I explained myself correctly. When I said sending CTRL-C 
programatically is not working, I meant, we're sending *gdb* the 
CTRL-C and that's not working; it has no effect. The expected 
behavior is that the inferior get interrupted and gdb takes control. 
Based on your comment, I believe you think we're sending the CTRL-C 
to the inferior. We do that as a fallback, and that does indeed work, 
but it's not an ideal solution. If nothing, we end up having to 
special case for cygwin 6.8, which is messy.

So, back to my question. If I'm able to manually do a CTRL-C within a 
cygwin 6.8 gdb session running in a Windows command shell, and it 
works, why doesn't it work when we (CDT) programatically send the gdb 
process we launched the CTRL-C. That's the mystery at hand. I suspect 
if we get an answer to that, it may help us address a range of issues 
related to interrupting gdb on Windows.






>With remote debugging, I think sending a ctrl-c to
>GDB should work, even in 6.8 (provided there's a console
>and GDB does get the CTRL_C_EVENT, or if this is a cygwin gdb,
>you sent it a real SIGINT signal).  Did you try it?
>
>--
>Pedro Alves

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Pedro Alves]

On Saturday 24 April 2010 02:57:03, John Cortell wrote:
> At 08:09 PM 4/23/2010, Pedro Alves wrote:
> >On Friday 23 April 2010 21:25:10, John Cortell wrote:
> > > cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb
> > > session successfully interrupts the target program, why is sending
> > > the CTRL-C programatically not working? Any thoughts there?
> >
> >In the latter case, is GDB sharing a console with the inferior?
> >If not sharing a console (native debugging, that is), newer GDB's
> >that postdate that patch Joel pointed you at, will catch the
> >CTRL_C_EVENT themselves, and still try to interrupt the inferior
> >with DebugBreakProcess.  Older GDB's, like 6.8, do nothing.
> 
> I'm not sure I explained myself correctly.

You had.

> When I said sending CTRL-C 
> programatically is not working, I meant, we're sending *gdb* the 
> CTRL-C and that's not working; it has no effect. 

Yes, I understood that correctly.

> The expected 
> behavior is that the inferior get interrupted and gdb takes control. 
> Based on your comment, I believe you think we're sending the CTRL-C 
> to the inferior.

I do not believe that.

> We do that as a fallback, and that does indeed work, 
> but it's not an ideal solution. If nothing, we end up having to 
> special case for cygwin 6.8, which is messy.
> 
> So, back to my question. If I'm able to manually do a CTRL-C within a 
> cygwin 6.8 gdb session running in a Windows command shell, and it 
> works, why doesn't it work when we (CDT) programatically send the gdb 
> process we launched the CTRL-C. That's the mystery at hand. I suspect 
> if we get an answer to that, it may help us address a range of issues 
> related to interrupting gdb on Windows.


I already answered that.  I'll try again.  In the latter case (when CDT
sends gdb the CTRL-C), if GDB is _not_ sharing a console with the inferior,
only GDB will get the CTRL_C_EVENT (that's how Windows works).  Before
the patch that Joel pointed you at (GDB 6.8 does not have that patch),
a CTRL_C_EVENT sent to GDB when the inferior is running does nothing.
The patch Joel pointed you at, made it so that when GDB gets a
CTRL_C_EVENT, and, gdb knows it is not sharing a console with the
inferior, then gdb knows that the inferior hasn't seen the CTRL_C_EVENT
as well, so it needs to take the job of interrupting the inferior
itself with DebugBreakProcess.  GDB 6.8 does not have that patch
applied, GDB simply ignores the CTRL_C_EVENT --- it does nothing,
as you say.  Try a more recent GDB, and things will probably work
a bit better.  Building a Cygwin GDB is very easy, there's nothing
to it (install a few devel packages using Cygwin's setup.exp;
./configure; make).  It would be quite helpful if frontend people
once in a while tried out top of tree (or recent) GDBs.

In a Windows command shell session (the former case you describe
as working), GDB _is sharing_ a console with the inferior, so
ctrl-c generates an event in all processes in the console
process group.  That is, the inferior also gets a CTRL_C_EVENT
automatically generated by Windows itself.  GDB intercepts this
event, like any other debug event, and reports it as SIGINT to the
frontend.  In this case, GDB _also_ receives the CTRL_C_EVENT event,
but, since it knows it is sharing the console with the inferior, it
simply ignores it.  Again, older GDBs, like 6.8, _always_ ignored
this CTRL_C_EVENT they themselves get; they didn't even install a
handler.

> >In the latter case, is GDB sharing a console with the inferior?
> >If not sharing a console (native debugging, that is), newer GDB's
> >that postdate that patch Joel pointed you at, will catch the
> >CTRL_C_EVENT themselves, and still try to interrupt the inferior
> >with DebugBreakProcess.  Older GDB's, like 6.8, do nothing.

> >With remote debugging, I think sending a ctrl-c to
> >GDB should work, even in 6.8 (provided there's a console
> >and GDB does get the CTRL_C_EVENT, or if this is a cygwin gdb,
> >you sent it a real SIGINT signal).  Did you try it?

-- 
Pedro Alves

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

At 09:13 PM 4/23/2010, Pedro Alves wrote:
>I already answered that.  I'll try again.  In the latter case (when CDT
>sends gdb the CTRL-C), if GDB is _not_ sharing a console with the inferior,
>only GDB will get the CTRL_C_EVENT (that's how Windows works).  Before
>the patch that Joel pointed you at (GDB 6.8 does not have that patch),
>a CTRL_C_EVENT sent to GDB when the inferior is running does nothing.

OK. Now I get it. It was the 'themselves' in '[gdb] will catch the
CTRL_C_EVENT themselves' that made me think there was a 
misunderstanding. Now I see we're on the same page.


>The patch Joel pointed you at, made it so that when GDB gets a
>CTRL_C_EVENT, and, gdb knows it is not sharing a console with the
>inferior, then gdb knows that the inferior hasn't seen the CTRL_C_EVENT
>as well, so it needs to take the job of interrupting the inferior
>itself with DebugBreakProcess.  GDB 6.8 does not have that patch
>applied, GDB simply ignores the CTRL_C_EVENT --- it does nothing,
>as you say.  Try a more recent GDB, and things will probably work
>a bit better.  Building a Cygwin GDB is very easy, there's nothing
>to it (install a few devel packages using Cygwin's setup.exp;
>./configure; make).  It would be quite helpful if frontend people
>once in a while tried out top of tree (or recent) GDBs.
>
>In a Windows command shell session (the former case you describe
>as working), GDB _is sharing_ a console with the inferior, so
>ctrl-c generates an event in all processes in the console
>process group.  That is, the inferior also gets a CTRL_C_EVENT
>automatically generated by Windows itself.  GDB intercepts this
>event, like any other debug event, and reports it as SIGINT to the
>frontend.  In this case, GDB _also_ receives the CTRL_C_EVENT event,
>but, since it knows it is sharing the console with the inferior, it
>simply ignores it.  Again, older GDBs, like 6.8, _always_ ignored
>this CTRL_C_EVENT they themselves get; they didn't even install a
>handler.

Great. That makes perfect sense now. So, given the behavior I'm 
seeing, it would seem the gdb that CDT launches is NOT sharing the 
console with the inferior. What is left for me to answer is "why?", 
since that's not what I expect. CDT, through an intermediary launcher 
process, does a  Win32 CreateProcess call to launch gdb. The call 
specifies whether to launch it attached or not, and if attached, 
whether to share the console. Fine, but that is between CDT's 
launcher process and gdb, not gdb and the inferior. The console 
relationship between gdb and the inferior seems out of the hands of 
CDT. That is, once we establish an mi connection with gdb, we till it 
to load aprogram.exe and run it. We don't specify whether gdb should 
share the console with it. So what's the expected behavior? Again, I 
would expect the two to share the console. After all, they apparently 
do when I carry out the same thing from a Windows command shell 
session. There too, I don't tell gdb to share a console with the 
inferior or not, and apparently it does.

OK. I'll give building cygwin gdb from HEAD a try, so I can have it 
around for reference. I appreciate your time on these questions, BTW. 
We're having a hell of a time interrupting the debugged program and 
hopefully this will help me get to the bottom of it.

John 

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Dave Korn]

On 24/04/2010 23:29, John Cortell wrote:

> Great. That makes perfect sense now. So, given the behavior I'm seeing,
> it would seem the gdb that CDT launches is NOT sharing the console with
> the inferior. What is left for me to answer is "why?", since that's not
> what I expect. CDT, through an intermediary launcher process, does a 
> Win32 CreateProcess call to launch gdb. The call specifies whether to
> launch it attached or not, and if attached, whether to share the
> console. Fine, but that is between CDT's launcher process and gdb, not
> gdb and the inferior. The console relationship between gdb and the
> inferior seems out of the hands of CDT. That is, once we establish an mi
> connection with gdb, we till it to load aprogram.exe and run it. We
> don't specify whether gdb should share the console with it. So what's
> the expected behavior? Again, I would expect the two to share the
> console. After all, they apparently do when I carry out the same thing
> from a Windows command shell session. There too, I don't tell gdb to
> share a console with the inferior or not, and apparently it does.

  What's probably getting in the way here is Cygwin's POSIX tty emulation,
which has to interact with the Windows console in bizarre and sometimes
unexpected ways.  A Cygwin process launched from a standard Windows console -
whether cmd.exe or bash doesn't matter - comes with its stdio handles attached
to the console.

  However, a Cygwin process launched either from a shell running in one of the
GUI consoles like xterm/rxvt, or if launched with CYGWIN=tty set in the
environment, gets connected to a pty, which is implemented in windows terms as
the ends of a pair of (iirc) named pipes.  In that case, no console is created
nor attached to the process, to avoid the "flashing black window" syndrome
caused by a console appearing briefly even if you hide it.

  I haven't checked what the code in gdb exactly tries to do when it launches
a process, but I'd infer from your observations that when the gdb itself is
running attached to a console it launches the inferior sharing the console,
and when not it may well let the new process create its own console.

  I quickly searched for "console" in the gdb info page, and discovered a
couple of useful-sounding options:

> `set new-console MODE'
>      If MODE is `on' the debuggee will be started in a new console on
>      next start.  If MODE is `off'i, the debuggee will be started in
>      the same console as the debugger.
> 
> `show new-console'
>      Displays whether a new console is used when the debuggee is
>      started.
> 
> `set new-group MODE'
>      This boolean value controls whether the debuggee should start a
>      new group or stay in the same group as the debugger.  This affects
>      the way the Windows OS handles `Ctrl-C'.
> 
> `show new-group'
>      Displays current value of new-group boolean.

  Those sound like they ought to be of some use to you in this situation :)

    cheers,
      DaveK

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell]

At 07:15 PM 4/24/2010, Dave Korn wrote:
>On 24/04/2010 23:29, John Cortell wrote:
>
> > Great. That makes perfect sense now. So, given the behavior I'm seeing,
> > it would seem the gdb that CDT launches is NOT sharing the console with
> > the inferior. What is left for me to answer is "why?", since that's not
> > what I expect. CDT, through an intermediary launcher process, does a
> > Win32 CreateProcess call to launch gdb. The call specifies whether to
> > launch it attached or not, and if attached, whether to share the
> > console. Fine, but that is between CDT's launcher process and gdb, not
> > gdb and the inferior. The console relationship between gdb and the
> > inferior seems out of the hands of CDT. That is, once we establish an mi
> > connection with gdb, we till it to load aprogram.exe and run it. We
> > don't specify whether gdb should share the console with it. So what's
> > the expected behavior? Again, I would expect the two to share the
> > console. After all, they apparently do when I carry out the same thing
> > from a Windows command shell session. There too, I don't tell gdb to
> > share a console with the inferior or not, and apparently it does.
>
>   What's probably getting in the way here is Cygwin's POSIX tty emulation,
>which has to interact with the Windows console in bizarre and sometimes
>unexpected ways.  A Cygwin process launched from a standard Windows console -
>whether cmd.exe or bash doesn't matter - comes with its stdio handles attached
>to the console.
>
>   However, a Cygwin process launched either from a shell running in 
> one of the
>GUI consoles like xterm/rxvt, or if launched with CYGWIN=tty set in the
>environment, gets connected to a pty, which is implemented in windows terms as
>the ends of a pair of (iirc) named pipes.  In that case, no console is created
>nor attached to the process, to avoid the "flashing black window" syndrome
>caused by a console appearing briefly even if you hide it.
>
>   I haven't checked what the code in gdb exactly tries to do when it launches
>a process, but I'd infer from your observations that when the gdb itself is
>running attached to a console it launches the inferior sharing the console,
>and when not it may well let the new process create its own console.
>
>   I quickly searched for "console" in the gdb info page, and discovered a
>couple of useful-sounding options:
>
> > `set new-console MODE'
> >      If MODE is `on' the debuggee will be started in a new console on
> >      next start.  If MODE is `off'i, the debuggee will be started in
> >      the same console as the debugger.
> >
> > `show new-console'
> >      Displays whether a new console is used when the debuggee is
> >      started.
> >
> > `set new-group MODE'
> >      This boolean value controls whether the debuggee should start a
> >      new group or stay in the same group as the debugger.  This affects
> >      the way the Windows OS handles `Ctrl-C'.
> >
> > `show new-group'
> >      Displays current value of new-group boolean.
>
>   Those sound like they ought to be of some use to you in this situation :)


Dave, that all got me pretty optimistic our problems would soon be 
over :-). Unfortunately, none of it panned out.

1. I ruled out POSIX emulation in the inferior being a factor by 
debugging a MinGW-built program. No change in behavior.CTRL-C to gdb 
programatically has no effect.
2. I added 'set new-console off' in the .gdbinit file (and confirmed 
it took effect with a 'show new-console' at debug time). No change in behavior.
3. I added 'set new-group on' in the .gdbinit file (and confirmed it 
took effect with a 'show new-group' at debug time). The default is 
on, btw. No change in behavior.

So, I decided to look at how we send the CTRL-C to gdb. If the 
program spawned by our launcher is using the cygwin runtime dll, we 
run  a 'kill -SIGINT <PID>'. In this case, the launched program is 
cygwin's gdb, which does use the cygwin runtime, so that's what we 
end up doing. And for sure, this command isn't interrupting either 
gdb or the inferior. So what I'll do tomorrow is see if we have more 
luck using the Win32 call GenerateConsoleCtrlEvent(CTRL_C_EVENT , 
0)...that's what we use when the launched program is not using the 
cygwin runtime.

Anyone know of a way to tell whether two running processes on Windows 
are sharing a console...perhaps via some utility? Process Explorer 
doesn't seem to reveal that information.

Again, I appreciate the insight.
John 

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Pedro Alves]

On Sunday 25 April 2010 15:09:22, John Cortell wrote:
> 1. I ruled out POSIX emulation in the inferior being a factor by 
> debugging a MinGW-built program. No change in behavior.CTRL-C to gdb 
> programatically has no effect.

Okay, at this point, we have some confusion in terminology.  When you
say "CTRL-C to GDB", I assume a CTRL_C_EVENT with
GenerateConsoleCtrlEvent.  Sending a SIGINT (Cygwin) signal is a
different story.  It is important that we understand exactly what
is what you're doing.

On Saturday 24 April 2010 23:29:21, John Cortell wrote:
> The call 
> specifies whether to launch it attached or not, and if attached, 
> whether to share the console. Fine, but that is between CDT's 
> launcher process and gdb, not gdb and the inferior.

But, is there a console to share at all?  Does the launcher
create one (even if hidden)?  Are you using "tty"/"set inferior-tty"
so GDB makes the inferior use it?

On Sunday 25 April 2010 15:09:22, John Cortell wrote:
> So, I decided to look at how we send the CTRL-C to gdb. If the 
> program spawned by our launcher is using the cygwin runtime dll, we 
> run  a 'kill -SIGINT <PID>'. In this case, the launched program is 
> cygwin's gdb, which does use the cygwin runtime, so that's what we 
> end up doing. And for sure, this command isn't interrupting either 
> gdb or the inferior. 

Looking at the code, this will not work with a Windows GDB in the case
of the inferior having been attaced to ("attach" vs "run").  Not even when
debugging a Cygwin inferior with a Cygwin GDB.  That works with native
debugging on linux (and other unixen), because those GDB ports install a
SIGINT handler that forwards the SIGINT to the inferior, whenever the
inferior is running.  This is all these set_sigint_trap calls do:

 >grep --exclude="ChangeLog*" set_sigint_trap *.c
 darwin-nat.c:      /* set_sigint_trap (); */
 inflow.c:/* Call set_sigint_trap when you need to pass a signal on to an attached
 inflow.c:set_sigint_trap (void)
 inf-ptrace.c:      set_sigint_trap ();
 inf-ttrace.c:      set_sigint_trap ();
 linux-nat.c:      set_sigint_trap ();
 linux-nat.c:  set_sigint_trap ();
 rs6000-nat.c:      set_sigint_trap ();
 spu-linux-nat.c:      set_sigint_trap ();       /* Causes SIGINT to be passed on to the


Note there's none in `windows-nat.c'.  I suppose that
if we added them to windows-nat.c, sending a real
Cygwin SIGINT to GDB would indeed forward it succesfully
the inferior, but iff the inferior is also a Cygwin
program.  It wouldn't work with a Cygwin GDB x MinGW
inferior, of course.

> 2. I added 'set new-console off' in the .gdbinit file (and confirmed 
> it took effect with a 'show new-console' at debug time). No change in behavior.

"off" is the default..

-- 
Pedro Alves

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Christopher Faylor]

Aren't we just circling around a simple problem here?  The latest
version of gdb has accommodations for CTRL-C, added by Joel.  The
current version, shipping with Cygwin does not.

cgf

RE: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Christopher Faylor
> Envoyé : Monday, April 26, 2010 8:22 AM
> À : Joel Brobecker; gdb@sourceware.org; Pedro Alves; John Cortell; Dave
> Korn
> Objet : Re: sending CTRL-C to Cygwin gdb 6.8 has no effect
> 
> Aren't we just circling around a simple problem here?  The latest
> version of gdb has accommodations for CTRL-C, added by Joel.  The
> current version, shipping with Cygwin does not.

  No I think that there is a different issue here:
The configuration of the Console when starting GDB.

  If the windows console is configured with
ENABLE_PROCESSED_INPUT via a call to SetConsoleMode,
then '^C' (ascii 3) is handled as an event, reported
to the debugger or passed to the program ConsoleCtrlHandler
if the function called SetConsoleCtrlHandler with the appropriate
arguments.

  The problem is that the state of the console is not
fixed when we start GDB. If ENABLE_PROCESSED_INPUT is not used
'^C' will be handled as a normal character.

  See for instance this small program:

start of program test.c
>>>>>>>>>>>>>>>>>>>>>>
#include <windows.h>

int
main (int argc, char **argv)
{
  int i;
  HANDLE std_in_handle = CreateFile ("CONIN$", GENERIC_READ | GENERIC_WRITE,
                              FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0);

  if (std_in_handle != INVALID_HANDLE_VALUE)
    {
      DWORD console_mode;
      (GetConsoleMode (std_in_handle, &console_mode));
      printf ("Console mode is 0x%x\n", console_mode);
      printf ("Console mode has ENABLE_PROCESSED_INPUT 0x%x\n",
        console_mode & ENABLE_PROCESSED_INPUT);
      if (argc > 1)
        console_mode = console_mode | ENABLE_PROCESSED_INPUT;
      else
        console_mode = console_mode & ~ ENABLE_PROCESSED_INPUT;

      printf ("New console mode is 0x%x\n", console_mode);
      (SetConsoleMode (std_in_handle, console_mode));
      (GetConsoleMode (std_in_handle, &console_mode));
      printf ("Console mode is 0x%x\n", console_mode);
    }
  /* This long loop allows to try to interrupt the program
     either by hitting Ctrl-C or Ctrl-Break.  */
  for (i = 1; i <= 600; i++)
    Sleep (1000);
}
>>>>>>>>>>>>>>>>>>>>>>
end of program test.c

gcc -mno-cygwin -g -o test.exe test.c

If you try to run test.exe of an ordinary Windows Console
(not under Cygwin).
  Using it without argument, you will disable ENABLE_PROCESSED_INPUT
thus Ctrl-C will not work for interruption.
CtrlBreak always works.
  If you use the program with any argument, you will 
enable ENABLE_PROCESSED_INPUT, and Ctrl-C will be able to 
interrupt the program.
  Notice also that (at least on my Command prompt) the initial value
of the console mode is always 0x1f. The last run of the program
does not change the value of the console after it finished.
  Inside Cygwin console, I get a different behavior:
'Ctrl-C' is always able to interrupt the program,
but this seems to be Cygwin specific (MSys console does not act the same
way).
  
  I will submit a patch to gdb-patches 
that will change the entry console mode to
include also ENABLE_PROCESSED_INPUT.


Pierre Muller
Pascal language support maintainer for GDB

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Christopher Faylor]

On Mon, Apr 26, 2010 at 01:38:01PM +0200, Pierre Muller wrote:
>  The problem is that the state of the console is not
>fixed when we start GDB. If ENABLE_PROCESSED_INPUT is not used
>'^C' will be handled as a normal character.

If we're talking about Cygwin (which is what's in the subject) then the
state of the console should be set.

cgf

Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[Pedro Alves]

On Monday 26 April 2010 14:21:47, John Cortell wrote:
>  I'm extremely happy to report that avoiding the 'kill' and going with GenerateConsoleCtrlEvent(CTRL_C_EVENT) works. No tweaking via the 'set' commands is even needed. So, it looks like our problems are over.

Great.

I think we may still have problems with "run" and GUI apps
(IMAGE_SUBSYSTEM_WINDOWS_GUI subsystem) that don't have a console
at all.  I haven't tried this in a while, but I think a console
ctrl-c event won't make it to the inferior, and GDB doesn't know to
resort automatically to some other means, like DebugBreakProcess.  Attaching
or setting "set new-console on" should help in this case.
I'd be happy to be proven wrong, though.  :-)

-- 
Pedro Alves