Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: John Cortell <rat042@freescale.com>
Cc: Dave Korn <dave.korn.cygwin@googlemail.com>,
	 gdb@sourceware.org,  Joel Brobecker <brobecker@adacore.com>
Subject: Re: sending CTRL-C to Cygwin gdb 6.8 has no effect
Date: Sun, 25 Apr 2010 21:25:00 -0000	[thread overview]
Message-ID: <201004252225.08587.pedro@codesourcery.com> (raw)
In-Reply-To: <201004251418.o3PEIBMG000580@az33smr01.freescale.net>

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


  reply	other threads:[~2010-04-25 21:25 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 [this message]
2010-04-26  6:22                       ` Christopher Faylor
2010-04-26 11:38                         ` Pierre Muller
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=201004252225.08587.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=dave.korn.cygwin@googlemail.com \
    --cc=gdb@sourceware.org \
    --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