Re: attach& support, and attach "async + sync_execution" support.

[Daniel Jacobowitz <drow@false.org>]

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