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: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 23 Jun 2011 14:59:52 -0600
- Subject: Re: [WIP/FYI] fix remaining problems with target async
- References: <201106131516.51434.pedro@codesourcery.com>
>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
Pedro> FYI, here's a work in progress patch I've been working
Pedro> on, in order to fix remaining target-async problems revealed
Pedro> by the testsuite, in order to start working on teaching gdb
Pedro> about run control ptsets.
I didn't want this to go uncommented-on. It seems like a very good
direction to me. I didn't read the patch in great detail though.
Pedro> I've been going back and forth with the design of the patch, as
Pedro> I've more than once followed a patch that looked great, only to
Pedro> trip on a nasty issue late on.
Sometimes I find it helpful to hear about the failed attempts as well;
if just to learn more about GDB.
Pedro> - force the sync and async command code to the same
Pedro> paths, by installing continuations in sync mode
Pedro> as well (and forcing a synchronous wait and running
Pedro> continuations when that's done).
This seems like a good cleanup regardless of the rest of the patch.
Pedro> - makes the command list code in cli/cli-script.c
Pedro> async aware, but turning into storing state in
Pedro> a state object, rather than relying on C's
Pedro> stack and nesting, and, installing a continuation
Pedro> and going back to the event loop waiting for an
Pedro> execution command to finish, whenever a command
Pedro> sets the target running in the foreground.
This is interesting. Does this open the door to making breakpoint
commands containing "finish" work? I don't actually know how this part
of GDB works...
Tom