This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Async mode fixes.
> Well, "target async" exists and has existed for a long time. I presume that
> when it was added, it fully worked. However, as it was not routinely tested,
> it has regressed to its current state.
I think the asynchronous mode wasn't completed and that it only ever worked for
remote targets. I'm starting to understand your patch now and see that your
changes just make the asynchronous mode of remote targets work - and that's a
sensible place to start.
> > You don't appear to have changed that. This is where I have issue with the
> > current `async' mode: it doesn't appear to use this continuation.
> Are you sure? I get the following with my patch:
> -interpreter-exec console continue
I've not tested your patch, just looked at it. This doesn't work in the
current code but I see now, as you say, that it's because target_executing is
not reset to 0, not because the continuation isn't called.
> Yes. Nick patch has two bits:
> 1. Linux native async mode (which Pedro is looking at as we speak)
> 2. Core async mode changes.
It really has three bits:
1. Core async mode changes.
2. Exec async mode changes.
3. Linux native async mode.
I think the command "target async" is a bit misleading and it should really be
called "target remote-async" (I'm not really suggesting changing it).
My changes aren't just for Linux, but an exec target. I mean native debugging
(I think) with just one implementation - linux. It sounds like I'm inflating
what I've done but other native targets can presumably be adapted to make use
of the changes in inf-ptrace.c, exec.c etc.
If all targets could run asynchronously, then it seems that that mode should
be specified at startup:
gdb --async myprog
in which case
(gdb) target remote host:2222
would do what
(gdb) target async host:2222
currently does and
would run the native applications asynchronously.