Canceling pagination caused by execution command from command line aborts readline/gdb

This fixes:

 $ ./gdb program -ex "set height 2" -ex "start"
 ...
 Reading symbols from /home/pedro/gdb/tests/threads...done.
 ---Type <return> to continue, or q <return> to quit---^CQuit  << ctrl-c triggers a Quit

 *type something*
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Usually, if an error propagates all the way to the top level, we'll
re-enable stdin, in case the command that was running was a
synchronous command.  That's done in the event loop's actual loop
(event-loop.c:start_event_loop).  However, if a foreground execution
command is run before the event loop starts and throws, nothing is
presently reenabling stdin, which leaves sync_execution set.

When we do start the event loop, because sync_execution is still
(mistakenly) set, display_gdb_prompt removes the readline input
callback, even though stdin is registered in the event loop.  Any
input from here on results in readline aborting.

Such commands are run through catch_command_errors,
catch_command_errors_const, so add the tweak there.

gdb/
2014-07-03  Pedro Alves  <palves@redhat.com>

	PR gdb/17072
	* main.c: Include event-top.h.
	(handle_command_errors): New function.
	(catch_command_errors, catch_command_errors_const): Use it.

gdb/testsuite/
2014-07-03  Pedro Alves  <palves@redhat.com>

	* gdb.base/paginate-execution-startup.c: New file.
	* gdb.base/paginate-execution-startup.exp: New file.
	* lib/gdb.exp (pagination_prompt): New global.
	(default_gdb_spawn): New procedure, factored out from
	default_gdb_spawn.
	(default_gdb_start): Adjust to call default_gdb_spawn.
	(gdb_spawn): New procedure.
Background execution + pagination aborts readline/gdb

If pagination occurs as result of output sent as response to a target
event while the target is executing in the background, subsequent
input aborts readline/gdb:

 $ gdb program
 ...
 (gdb) continue&
 Continuing.
 (gdb)
 ---Type <return> to continue, or q <return> to quit---
 *return*
 ---Type <return> to continue, or q <return> to quit---
 Breakpoint 2, after_sleep () at paginate-bg-execution.c:21
 ---Type <return> to continue, or q <return> to quit---
 21        return; /* after sleep */
 p 1
 readline: readline_callback_read_char() called with no handler!
 *abort/SIGABRT*
 $

gdb_readline_wrapper_line removes the handler after a line is
processed.  Usually, we'll end up re-displaying the prompt, and that
reinstalls the handler.  But if the output is coming out of handling
a stop event, we don't re-display the prompt, and nothing restores the
handler.  So the next input wakes up the event loop and calls into
readline, which aborts.

We should do better with the prompt handling while the target is
running (I think we should coordinate with readline, and
hide/redisplay it around output), but that's a more invasive change
better done post 7.8, so this patch is conservative and just
reinstalls the handler as soon as we're out of the readline line
callback.

gdb/
2014-07-03  Pedro Alves  <palves@redhat.com>

	PR gdb/17072
	* top.c (gdb_readline_wrapper_line): Tweak comment.
	(gdb_readline_wrapper_cleanup): If readline is enabled, reinstall
	the input handler callback.

gdb/testsuite/
2014-07-03  Pedro Alves  <palves@redhat.com>

	PR gdb/17072
	* gdb.base/paginate-bg-execution.c: New file.
 	* gdb.base/paginate-bg-execution.exp: New file.
Remove the target from the event loop while in secondary prompts

If a pagination prompt triggers while the target is running, and the
target exits before the user responded to the pagination query, this
happens:

  Starting program: foo
  ---Type <return> to continue, or q <return> to quit---No unwaited-for children left.
  Couldn't get registers: No such process.
  Couldn't get registers: No such process.
  Couldn't get registers: No such process.
  (gdb) Couldn't get registers: No such process.
  (gdb)

To reiterate, the user hasn't replied to the pagination prompt above.

A pagination query nests an event loop (in gdb_readline_wrapper).  In
async mode, in addition to stdin and signal handlers, we'll have the
target also installed in the event loop still.  So if the target
reports an event, that wakes up the nested event loop, which calls
into fetch_inferior_event etc. to handle the event which generates
further output, all while we should be waiting for pagination
confirmation...

(TBC, any target event that generates output ends up spuriously waking
up the pagination, though exits seem to be the worse kind.)

I've played with a couple different approaches to fixing this, while
at the same time trying to avoid being invasive.  Both revolve around
not listening to target events while in a pagination prompt (doing
anything else I think would be a much bigger change).

The approach taken just removes the target from the event loop while
within gdb_readline_wrapper.  The other approach used gdb_select
directly, with only input_fd installed, but that had the issue that it
didn't handle the async signal handlers, and turned out to be a bit
more code than the first version.

gdb/
2014-07-03  Pedro Alves  <palves@redhat.com>

	PR gdb/17072
	* top.c: Include "inf-loop.h".
	(struct gdb_readline_wrapper_cleanup) <target_is_async_orig>: New
	field.
	(gdb_readline_wrapper_cleanup): Make the target async again, if it
	was async before.
	(gdb_readline_wrapper): Store whether the target is async, and
	make it sync.

gdb/testsuite/
2014-07-03  Pedro Alves  <palves@redhat.com>

	PR gdb/17072
	* gdb.base/paginate-inferior-exit.c: New file.
	* gdb.base/paginate-inferior-exit.exp: New file.
Fix double prompt

If an error is thrown while handling a target event (within
fetch_inferior_event), and, the interpreter is not async (but the
target is), then GDB prints the prompt twice.

One way to see that in action is throw a QUIT while in a pagination
prompt issued from within fetch_inferior_event (or one of its
callees).  E.g. from the test:

 ---Type <return> to continue, or q <return> to quit---
 ^CQuit
 (gdb) (gdb) p 1
 ^^^^^^^^^^^
 $1 = 1
 (gdb)

The issue is that inferior_event_handler swallows errors and notifies
the observers (the interpreters) about the command error, even if the
interpreter is forced sync while we're handling a nested event loop
(for execute_command).  The observers print a prompt, and then when we
get back to the top event loop, we print another (in
start_event_loop).

I see no reason the error should be swallowed here.  Just cancel the
execution related bits and let the error propagate to the top level
(start_event_loop), which re-enables stdin and notifies observers.

gdb/
2014-07-03  Pedro Alves  <palves@redhat.com>

	* inf-loop.c (inferior_event_handler): Use TRY_CATCH instead of
	catch_errors.  Don't re-enable stdin or notify observers where,
	and rethrow error.
	(fetch_inferior_event_wrapper): Delete.

gdb/testsuite/
2014-07-03  Pedro Alves  <palves@redhat.com>

	* gdb.base/double-prompt-target-event-error.c: New file.
	* gdb.base/double-prompt-target-event-error.exp: New file.
Put GDB's terminal settings into effect when paginating.

When the target is resumed in the foreground, we put the inferior's
terminal settings into effect, and remove stdin from the event loop.
When the target stops, we put GDB's terminal settings into effect
again, and re-register stdin in the event loop, ready for user input.
The former is done by target_terminal_inferior, and the latter by
target_terminal_ours.

There's an intermediate -- target_terminal_ours_for_output -- that is
called when printing output related to target events, and we don't
know yet whether we'll stop the program.  That puts our terminal
settings into effect, enough to get proper results from our output,
but leaves input wired into the inferior.

If such output paginates, then we need the full target_terminal_ours
in order for the user to be able to provide input to answer the
pagination query.

The test in this commit hangs in async-capable targets without the fix
(as the user/test can't answer the pagination query).  It doesn't hang
on sync targets because on those we don't unregister stdin from the
event loop while the target is running (because we block in
target_wait instead of in the event loop in that case).

gdb/
2014-07-03  Pedro Alves  <palves@redhat.com>

	* utils.c (prompt_for_continue): Call target_terminal_ours.

gdb/testsuite/
2014-07-03  Pedro Alves  <palves@redhat.com>

	* gdb.base/paginate-after-ctrl-c-running.c: New file.
 	* gdb.base/paginate-after-ctrl-c-running.exp: New file.
Fix "attach" command vs user input race

On async targets, a synchronous attach is done like this:

   #1 - target_attach is called (PTRACE_ATTACH is issued)
   #2 - a continuation is installed
   #3 - we go back to the event loop
   #4 - target reports stop (SIGSTOP), event loop wakes up, and
        attach continuation is called
   #5 - among other things, the continuation calls
        target_terminal_inferior, which removes stdin from the event
        loop

Note that in #3, GDB is still processing user input.  If the user is
fast enough, e.g., with something like:

  echo -e "attach PID\nset xxx=1" | gdb

... then the "set" command is processed before the attach completes.

We get worse behavior even, if input is a tty and therefore
readline/editing is enabled, with e.g.,:

 (gdb) attach PID\nset xxx=1

we then crash readline/gdb, with:

 Attaching to program: attach-wait-input, process 14537
 readline: readline_callback_read_char() called with no handler!
 Aborted
 $

Fix this by calling target_terminal_inferior before #3 above.

The test covers both scenarios by running with editing/readline forced
to both on and off.

gdb/
2014-07-04  Pedro Alves  <palves@redhat.com>

	* infcmd.c (attach_command_post_wait): Don't call
	target_terminal_inferior here.
	(attach_command): Call it here instead.

gdb/testsuite/
2014-07-04  Pedro Alves  <palves@redhat.com>

	* gdb.base/attach-fg-no-stdin.exp: New file.
	* gdb.base/attach-fg-no-stdin.c: New file.