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: [RFA] Async mode fixes.


On Monday 10 March 2008 12:11:58 Nick Roberts wrote:
>  > Likewise, I think it's better to always use async mode,
>  > if the target supports it. We're not at the point when we can do
>  > it -- even with my patch, 'target async' has a couple of extra
>  > failures relatively to 'target remote', and I never tried getting
>  > test results for linux native -- but I think having async mode
>  > always on should be end goal.
> 
> The patch isn't perfect, e.g., you say:
> 
>   I get the following with my patch:
> 
> 	(gdb)
> 	-interpreter-exec console continue
> 	~"Continuing.\n"
> 	^running
> 	*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",.....
> 
> but that should be:
> 
> 	(gdb)
> 	-interpreter-exec console continue
> 	~"Continuing.\n"
> 	^running
> 	(gdb)
> 	*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",.....
> 
> because in mi_execute_command, args.action == EXECUTE_COMMAND_SUPRESS_PROMPT
> when it should be EXECUTE_COMMAND_DISPLAY_PROMPT.  This in turn is because
> sync_execution is 1 when it should be 0.  Note that in Apple's code
> sync_execution doesn't get toggled by async_enable/disable_stdin,

You mean this bit of code:

     else if (sync_execution)
	{
	  /* Don't print the prompt. We are executing the target in
	     synchronous mode.  */
	  args->action = EXECUTE_COMMAND_SUPRESS_PROMPT;
	  return;
	}

? I actually planned to remove it without further ado, after this async
patch goes in. My reasoning is that the current behaviour is just bizarre. For sync
target, any exec commands results in 

	^running
	(gdb) 

whereas for async target, due to above fragment, you can sometimes not get
a prompt -- and this is backward.

Of course, this code only deals with printing the prompt, whereas we still have the
bigger issue -- namely that if we execute "continue" using -interpreter-exec,
then GDB does not accept the input while continue runs, and -exec-interrupt
does not work. Apple branch fixes that by not setting sync_execution inside
async_disable_stdin, but I find the fix suspect -- if we give up
terminal to inferior and then try to read something, I'm not sure it will
work. It does work with "target async", but target async does not actually
mess with terminal.

One solution is probably to never disable stdin when an external tty
is used for program output. Or to never disable stdin when top-level
interpreter is MI. I must admit I don't know the right solution, yet.

- Volodya


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