On Mon, Jul 6, 2009 at 3:34 PM, Daniel Jacobowitz
<drow@xxxxxxxxx> wrote:
On Fri, Jul 03, 2009 at 09:05:55AM -0400, Marc Khouzam wrote:
> I'm not very knowledgeable about signals so what I would do
> is set a breakpoint in CDT to see if we are trying to send
> the signal.
Signals... Oh, let me tell you about signals on Windows. It doesn't
have any. The closest thing is an interrupt event, which is
associated with a console. I haven't looked at the source for CDT's
Spawner, but the odds are very good that it isn't creating a Windows
console for GDB; it's possible but infuriatingly hard to do this
without popping up a visible console window.
You can stop the debugged program using a debug break event. You
have to either send it directly, or tell GDB to; if you somehow get a
CTRL_C_EVENT to the GDB process, it will do this for you.
If you use -exec-interrupt it will send a CTRL_C_EVENT to the
debuggee. I don't know why this difference; you'd have to ask
on the GDB list and Chris Faylor can probably explain.
(Yes, I realize none of this explains how the previous CDT integration
handled it... sorry, I don't know, but this may be helpful anyway.
I scream in horror at the memories that are now mostly faded due to the shock of spending a few weeks trying to get this working on Windows.
Now from what I remember this is handled by using Windows Events to send a "signal" from the spawner.dll native to the starter.exe process which launches gdb. The starter does the CTRL_C_EVENT to itself to interrupt gdb. I think...
--
Daniel Jacobowitz
CodeSourcery
