This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP/FYI] fix remaining problems with target async


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]