This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [WIP/FYI] fix remaining problems with target async
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Tue, 30 Aug 2011 15:38:46 +0100
- Subject: Re: [WIP/FYI] fix remaining problems with target async
- References: <201106131516.51434.pedro@codesourcery.com> <20110826233850.GA27471@host1.jankratochvil.net>
On Saturday 27 August 2011 00:38:50, Jan Kratochvil wrote:
> On Mon, 13 Jun 2011 16:16:51 +0200, Pedro Alves wrote:
> > Rather than leaving it rotting on my drive, I figure I'd post it, and
> > perhaps get some early comments.
>
> Posting a purely mechanical rebase to HEAD.
Thanks.
> By a brief reading I do not see there any problem, I also do not see any
> regressions. It for example fixes:
> ./gdb -nx ./gdb -ex 'set target-async on' -ex start -ex step
> Cannot execute this command while the selected thread is running.
Eh, I'm surprised that this worked at all. :-) We end up prepending
the step continuation before "start" finishes, and forcing all those
to finish. It works by accident.
Example, this will still not work the same sync vs async:
-ex "start" -ex "step" -ex "si"
with async being broken, due to that continuation mess up.
> I had difficulties developing the async part of the bpstat_clear_actions patch
> as one has to avoid various async bugs in the current code.
>
> Unless you have very specific plans with it I would find it as a nice
> incremental improvement (+few comments for the new objects would be
> appropriate).
I plan on getting back to it a bit later on (and split it up into smaller
pieces), after making more progress with ptsets stuff; the patch as is
breaks some cases that end up nesting continuations, and probably other cases.
Meanwhile, I'd like to go with <http://sourceware.org/ml/gdb/2011-08/msg00124.html>
instead as first step, with the idea that with that patch, sync on top of async
will work correctly _now_, and we consider flipping on async on by default _now_,
and then incrementally convert specific paths to state machines, for new use
cases, rather than delaying flipping on async on by default
until _everything_ is converted into a state-machine, which I'm
convinced will not be possible / sane anyway.
Can you give that one a try? It should fix the -ex ... use cases.
--
Pedro Alves