From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
To: "'Christopher Faylor'"
<cgf-use-the-mailinglist-please@sourceware.org>,
"'Joel Brobecker'" <brobecker@adacore.com>,
<gdb@sourceware.org>,
"'Pedro Alves'" <pedro@codesourcery.com>,
"'John Cortell'" <rat042@freescale.com>,
"'Dave Korn'" <dave.korn.cygwin@googlemail.com>
Subject: RE: sending CTRL-C to Cygwin gdb 6.8 has no effect
Date: Mon, 26 Apr 2010 11:38:00 -0000 [thread overview]
Message-ID: <005101cae534$ed96bee0$c8c43ca0$@muller@ics-cnrs.unistra.fr> (raw)
In-Reply-To: <20100426062203.GA31312@ednor.casa.cgf.cx>
> -----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
next prev parent reply other threads:[~2010-04-26 11:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 19:33 John Cortell
2010-04-23 19:44 ` Joel Brobecker
2010-04-23 19:57 ` John Cortell
2010-04-23 20:11 ` Joel Brobecker
2010-04-23 20:27 ` John Cortell
2010-04-24 1:10 ` Pedro Alves
2010-04-24 1:58 ` John Cortell
2010-04-24 2:13 ` Pedro Alves
2010-04-24 22:30 ` John Cortell
2010-04-24 23:56 ` Dave Korn
2010-04-25 14:10 ` John Cortell
2010-04-25 21:25 ` Pedro Alves
2010-04-26 6:22 ` Christopher Faylor
2010-04-26 11:38 ` Pierre Muller [this message]
2010-04-26 14:30 ` Christopher Faylor
[not found] ` <201004261330.o3QDUfph028936@az33smr01.freescale.net>
2010-04-26 13:37 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='005101cae534$ed96bee0$c8c43ca0$@muller@ics-cnrs.unistra.fr' \
--to=pierre.muller@ics-cnrs.unistra.fr \
--cc=brobecker@adacore.com \
--cc=cgf-use-the-mailinglist-please@sourceware.org \
--cc=dave.korn.cygwin@googlemail.com \
--cc=gdb@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=rat042@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox