Community
Participate
Working Groups
Daniel Jacobowitz wrote in http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg17533.html "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." We should try to use the new GDB 7.0 async mode.
GDB async mode requires target side support, and that needs to implemented on a per-target basis (target here refers to the part of GDB that abstracts the underlying debug APIs). Currently (gdb 7.1), it's implemented on the native linux target, and on the remote target; The latter means that async mode works against a Windows gdbserver, as one connects to gdbserver using the remote target. The native Windows target does not support async mode, yet.
(In reply to comment #1) > GDB async mode requires target side support, and that needs to > implemented on a per-target basis (target here refers to the part > of GDB that abstracts the underlying debug APIs). > > Currently (gdb 7.1), it's implemented on the native linux target, and > on the remote target; The latter means that async mode works against > a Windows gdbserver, as one connects to gdbserver using the remote target. > > The native Windows target does not support async mode, yet. Thanks Pedro. So this bug dies here, right? We wanted it for Windows. I had started trying it out and I had all kinds of trouble on Linux (with 7.0.1). Is MI automatically asynchronous? I mean, when I do -exec-run should I be able to do some commands after or is there some thing like CLI run& that needs to be done.
[reposting using the bugzilla web client; my yesterday's reply by email (below) doesn't seem to have gotten through somehow.] > So this bug dies here, right? We wanted it for Windows. Dunno the policies here. You could leave it suspended and point people here whenever the issue is raised. It's not implemented today, but I'm sure it will be someday. These things tend to be implemented faster if some interested party drives the effort though. ;-) > I had started trying it out and I had all kinds of trouble on Linux (with > 7.0.1). Is MI automatically asynchronous? I mean, when I do -exec-run should > I be able to do some commands after or is there some thing like CLI run& that > needs to be done. I see what you mean. Yes, you're right. On 7.0 and 7.1, -exec-run maps directly to "run", so you'll need to use CLI's "run&" as a workaround. This is because the target non-stop was designed for initially only cared for -exec-attach, but you know that. :-) HEAD (future 7.2) has been fixed already. -exec-run behaves the same CLI's "run&" when async is on there.
(In reply to comment #3) > [reposting using the bugzilla web client; my yesterday's reply by email > (below) doesn't seem to have gotten through somehow.] I don't believe bugzilla has the nice feature of allowing you to reply by email. You have to go through the web, from what I've seen. > > So this bug dies here, right? We wanted it for Windows. > > Dunno the policies here. You could leave it suspended > and point people here whenever the issue is raised. > It's not implemented today, but I'm sure it will be someday. > These things tend to be implemented faster if some > interested party drives the effort though. ;-) Yep, we'll leave the bug opened, but I just wanted to make sure I properly understood that it won't work on Windows today. Which you now made clear. > > I had started trying it out and I had all kinds of trouble on Linux (with > > 7.0.1). Is MI automatically asynchronous? I mean, when I do -exec-run should > > I be able to do some commands after or is there some thing like CLI run& that > > needs to be done. > I see what you mean. Yes, you're right. On 7.0 and 7.1, > -exec-run maps directly to "run", so you'll need to > use CLI's "run&" as a workaround. This is because > the target non-stop was designed for initially > only cared for -exec-attach, but you know that. :-) > > HEAD (future 7.2) has been fixed already. -exec-run > behaves the same CLI's "run&" when async is on there. Great, good to know. I often get confused about these little details.
