RE: [cdt-dev] target unexpectedly stops on a SIGINT while setting breakp

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Jacobowitz
> Sent: March-03-10 6:16 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] target unexpectedly stops on a SIGINT 
> while setting breakpoint on running target
> 
> On Tue, Mar 02, 2010 at 05:52:39PM -0600, John Cortell wrote:
> >    I'm encountering an intermittent problem setting a 
> breakpoint while the
> >    target is running on mingw/gdb 7.0. The target ends up becoming
> >    unexpectedly suspended because of a SIGINT.
> > 
> >    The target program is in the middle of a Win32 Sleep() 
> call when I try to
> >    set the breakpoint. The next thing I expect to happen is that the
> >    breakpoint is hit. Instead, the target stops in an 
> unexpected location.
> >    Interestingly enough, gdb seems to warn the debugger 
> that this is going to
> >    happen (see bold/red trace line below). Any gdb experts 
> out there know why
> >    this is happening?
> 
> Interrupting things on Windows is a mess.  The fact that for 
> historical reasons, CDT does this by sending an actual C-c or 
> DebugBreak to GDB makes it even worse.
> 
> The real solution to this problem is to not interrupt GDB.  
> Instead, drive GDB in asynchronous mode.  Then send 
> -exec-interrupt.  We've made some big contributions to GDB 
> over the last two years to make this work smoothly.
> 
> I think DSF does, or can do, this.  Marc Khouzam should know for sure.

We only use async mode when using non-stop.  I did consider making the switch
but two things stopped me:

1- lots of regression testing since everything would be using asych GDB mode
instead of the traditional synch mode.
2- We still need to support older GDBs (we support 6.6 and up), so we'd still
need to keep the code for the sync mode.

If it is a big enough problem, we could give it a try for GDB 7.0 and fix the problem
there only, but I'm not sure it is worth the effort.

Marc