This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: attach& support, and attach "async + sync_execution" support.
On Mon, Mar 17, 2008 at 03:48:09PM +0000, Pedro Alves wrote:
> A Friday 14 March 2008 19:18:21, Daniel Jacobowitz wrote:
> > Could you do some refactoring on this, please? It duplicates code
> > from attach_command. When I fixed up step last year I moved the
> > common code into its own function. Makes it much easier to see
> > the differences between async and sync operation. And for instance
> > it lets me see that you're calling deprecated_attach_hook twice
> > in async mode :-)
>
> I don't think I was :-) There were three different exit points.
> sync, async/sync_execution, and true async.
Yep, you're correct. OK, it lets me confuse myself.
> (P.S. Am I the only one that thinks that continuation
> arguments suck? IMHO, we should move the continuation_arg data
> union into the continuation proper, and force people to use
> structs for the compound args. Oh, and who is responsible for
> freeing the continuation args? Nobody seems to be doing that.)
Yes, this is a mess. Maybe we should go back to just passing a void
*...
> + if (args)
> + {
> + async_exec = strip_bg_char (&args);
> +
> + /* If we get a request for running in the bg but the target
> + doesn't support it, error out. */
> + if (async_exec && !target_can_async_p ())
> + error (_("Asynchronous execution not supported on this target."));
> +
> + /* If we don't get a request of running in the bg, then we need
> + to simulate synchronous (fg) execution. */
> + if (!async_exec && target_can_async_p ())
> + {
> + /* Simulate synchronous execution */
> + async_disable_stdin ();
> + }
> + }
This logic will work, since args should never be NULL anyway, but the
call to async_disable_stdin is not dependent on args I think?
Otherwise OK.
--
Daniel Jacobowitz
CodeSourcery