Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Lift DWARF unwinder restriction in dwarf2-frame.c::dwarf2_frame_cfa

GDB is currently broken on all SPARC targets when using GCC 4.9.
When trying to print any local variable:

    (gdb) p x
    can't compute CFA for this frame

This is related to the fact that the compiler now generates DWARF 4
debugging info by default, and in particular that it now emits
DW_OP_call_frame_cfa, which triggers a limitation in dwarf2_frame_cfa:

   /* This restriction could be lifted if other unwinders are known to
      compute the frame base in a way compatible with the DWARF
      unwinder.  */
   if (!frame_unwinder_is (this_frame, &dwarf2_frame_unwind)
       && !frame_unwinder_is (this_frame, &dwarf2_tailcall_frame_unwind))
     error (_("can't compute CFA for this frame"));

We couldn't append the dwarf2 unwinder to all SPARC targets because
it does not work properly with StackGhost:
    https://www.sourceware.org/ml/gdb-patches/2014-07/msg00012.html

We also later discovered that using the DWARF2 unwinder means
using it for computing the function's return address, which
is buggy when it comes to functions returning a struct (where
the return address is saved-pc+12 instead of saved-pc+8).
This is because GCC is emitting the info about the return address
as %o7/%i7 instead of the actual return address.  For functions
that have debugging info, we compensate by looking at the function's
return type and add the extra +4, but for function without debug
info, we're stuck.

EricB and I twisted the issue in all the directions we could think of,
and unfortunately couldn't find a way to make it work without
introduction one regression or another.

But, stepping back a little, just removing the restriction seems to work
well for us on all both sparc-elf and {sparc,sparc64}-solaris.
After reviewing the previous discussions about this test, I could
not figure out whether some unwinders were already known to have
incompatible CFAs or if the concern was purely theoretical:
    https://www.sourceware.org/ml/gdb-patches/2009-06/msg00191.html
    https://www.sourceware.org/ml/gdb-patches/2009-07/msg00570.html
    https://www.sourceware.org/ml/gdb-patches/2009-09/msg00027.html

At the moment, we took the approach of trying it out, and see what
happens...

gdb/ChangeLog:

        PR backtrace/16215:
        * dwarf2-frame.c (dwarf2_frame_cfa): Remove the restriction
        the frame unwinder must either be the dwarf2_frame_unwind
        or the dwarf2_tailcall_frame_unwind.  Verify that this_frame's
        stack_addr is valid before calling get_frame_base.  Throw
        an error if not valid.

Tested on sparc-solaris and sparc-elf with AdaCore's testsuite
(the FSF testsuite crashes all of AdaCore's solaris machines).

Automatic date update in version.in

Fix executable indicator in file name completion on Windows.

* complete.c (stat_char) [_WIN32]: Don't use 'access' and X_OK on
Windows, they don't work.  Instead, look at the file-name
extension to determine whether the file is executable.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Add _bfd_elf_ifunc_get_synthetic_symtab

In i386 and x86-64 binaries with ifunc, relocations against .got.plt
section may not be in the same order as entries in PLT section.  This
patch adds _bfd_elf_ifunc_get_synthetic_symtab.  It takes a function
pointer which returns an array of PLT entry symbol values.  It calls
the function pointer to get the PLT entry symbol value array indexed
by relocation index, instead of calling plt_sym_val on each relocation
index.

PR binutils/17677
* elf-bfd.h (_bfd_elf_ifunc_get_synthetic_symtab): New prototype.
* elf-ifunc.c (_bfd_elf_ifunc_get_synthetic_symtab): New
function.
* elf32-i386.c (elf_i386_plt_sym_val): Removed.
(elf_backend_plt_sym_val): Likewise.
(elf_i386_get_plt_sym_val): New.
(elf_i386_get_synthetic_symtab): Likewise.
(bfd_elf32_get_synthetic_symtab): Likewise.
* elf64-x86-64.c (elf_x86_64_plt_sym_val): Removed.
(elf_x86_64_plt_sym_val_offset_plt_bnd): Likewise.
(elf_backend_plt_sym_val): Likewise.
(elf_x86_64_get_plt_sym_val): New.
(bfd_elf32_get_synthetic_symtab): Likewise.
(elf_x86_64_get_synthetic_symtab): Use
_bfd_elf_ifunc_get_synthetic_symtab.
(bfd_elf64_get_synthetic_symtab): Don't undefine for NaCl.

Fix 7.8 regression: resolve_dynamic_struct: Assertion `TYPE_NFIELDS (type) > 0' (PR 17642)

https://sourceware.org/bugzilla/show_bug.cgi?id=17642

Regression since:
commit 012370f6818657a816df1463ee71ca4e4ee40b33
Author: Tom Tromey <tromey@redhat.com>
Date:   Thu May 8 11:26:44 2014 -0600
    handle VLA in a struct or union

Bugreport:
Regression with gdb scripts for Linux kernel
https://sourceware.org/ml/gdb/2014-08/msg00127.html

That big change after "else" is just reindentation.

gdb/ChangeLog
2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

PR symtab/17642
* gdbtypes.c (resolve_dynamic_type_internal): Apply check_typedef to
TYPE if not TYPE_CODE_TYPEDEF.

gdb/testsuite/ChangeLog
2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

PR symtab/17642
* gdb.base/vla-stub-define.c: New file.
* gdb.base/vla-stub.c: New file.
* gdb.base/vla-stub.exp: New file.

Reindent code (resolve_dynamic_type_internal).

gdb/ChangeLog
2014-12-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdbtypes.c (resolve_dynamic_type_internal): Reindent the code.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 7.8.1.DATE-cvs.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.8.1.DATE-cvs.

Document the GDB 7.8.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.8.1 released.

Set GDB version number to 7.8.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.8.1.

PR 17408 - assertion failure in switch_back_to_stepped_thread

This PR shows that GDB can easily trigger an assertion here, in
infrun.c:

 5392              /* Did we find the stepping thread?  */
 5393              if (tp->control.step_range_end)
 5394                {
 5395                  /* Yep.  There should only one though.  */
 5396                  gdb_assert (stepping_thread == NULL);
 5397
 5398                  /* The event thread is handled at the top, before we
 5399                     enter this loop.  */
 5400                  gdb_assert (tp != ecs->event_thread);
 5401
 5402                  /* If some thread other than the event thread is
 5403                     stepping, then scheduler locking can't be in effect,
 5404                     otherwise we wouldn't have resumed the current event
 5405                     thread in the first place.  */
 5406                  gdb_assert (!schedlock_applies (currently_stepping (tp)));
 5407
 5408                  stepping_thread = tp;
 5409                }

Like:

 gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.

The way the assertion is written is assuming that with schedlock=step
we'll always leave threads other than the one with the stepping range
locked, while that's not true with the "next" command.  With schedlock
"step", other threads still run unlocked when "next" detects a
function call and steps over it.  Whether that makes sense or not,
still, it's documented that way in the manual.  If another thread hits
an event that doesn't cause a stop while the nexting thread steps over
a function call, we'll get here and fail the assertion.

The fix is just to adjust the assertion.  Even though we found the
stepping thread, we'll still step-over the breakpoint that just
triggered correctly.

Surprisingly, gdb.threads/schedlock.exp doesn't have any test that
steps over a function call.  This commits fixes that.  This ensures
that "next" doesn't switch focus to another thread, and checks whether
other threads run locked or not, depending on scheduler locking mode
and command.  There's a lot of duplication in that file that this ends
cleaning up.  There's more that could be cleaned up, but that would
end up an unrelated change, best done separately.

This new coverage in schedlock.exp happens to trigger the internal
error in question, like so:

 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0)
 FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount)

That's because we have more than one thread running the same loop, and
while one thread is stepping over a function call, the other thread
hits the step-resume breakpoint of the first, which needs to be
stepped over, and we end up in switch_back_to_stepped_thread exactly
in the problem case.

I think a simpler and more directed test is also useful, to not rely
on internal breakpoint magics.  So this commit also adds a test that
has a thread trip on a conditional breakpoint that doesn't cause a
user-visible stop while another thread is stepping over a call.  That
currently fails like this:

 FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error)

Tested on x86_64 Fedora 20.

gdb/
2014-10-29  Pedro Alves  <palves@redhat.com>

PR gdb/17408
* infrun.c (switch_back_to_stepped_thread): Use currently_stepping
instead of assuming a thread with a stepping range is always
stepping.

gdb/testsuite/
2014-10-29  Pedro Alves  <palves@redhat.com>

PR gdb/17408
* gdb.threads/schedlock.c (some_function): New function.
(call_function): New global.
(MAYBE_CALL_SOME_FUNCTION): New macro.
(thread_function): Call it.
* gdb.threads/schedlock.exp (get_args): Add description parameter,
and use it instead of a global counter.  Adjust all callers.
(get_current_thread): Use "find current thread" for test message
here rather than having all callers pass down the same string.
(goto_loop): New procedure, factored out from ...
(my_continue): ... this.
(step_ten_loops): Change parameter from test message to command to
use.  Adjust.
(list_count): Delete global.
(check_result): New procedure, factored out from duplicate top
level code.
(continue tests): Wrap in with_test_prefix.
(test_step): New procedure, factored out from duplicate top level
code.
(top level): Test "step" in combination with all scheduler-locking
modes.  Test "next" in combination with all scheduler-locking
modes, and in combination with stepping over a function call or
not.
* gdb.threads/next-bp-other-thread.c: New file.
* gdb.threads/next-bp-other-thread.exp: New file.

PR python/17372 - Python hangs when displaying help()

This is more of a readline/terminal issue than a Python one.

PR17372 is a regression in 7.8 caused by the fix for PR17072:

 commit 0017922d0292d8c374584f6100874580659c9973
 Author: Pedro Alves <palves@redhat.com>
 Date:   Mon Jul 14 19:55:32 2014 +0100

    Background execution + pagination aborts readline/gdb

    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.
...
    gdb/
    2014-07-14  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.

The problem is that installing the input handler callback also preps
the terminal, putting it in raw mode and with echo disabled, which is
bad if we're going to call a command that assumes cooked/canonical
mode, and echo enabled, like in the case of the PR, Python's
interactive shell.  Another example I came up with that doesn't depend
on Python is starting a subshell with "(gdb) shell /bin/sh" from a
multi-line command.  Tests covering both these examples are added.

The fix is to revert the original fix for PR gdb/17072, and instead
restore the callback handler after processing an asynchronous target
event.

Furthermore, calling rl_callback_handler_install when we already have
some input in readline's line buffer discards that input, which is
obviously a bad thing to do while the user is typing.  No specific
test is added for that, because I first tried calling it even if the
callback handler was still installed and that resulted in hundreds of
failures in the testsuite.

gdb/
2014-10-29  Pedro Alves  <palves@redhat.com>

PR python/17372
* event-top.c (change_line_handler): Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(callback_handler_installed): New global.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New functions.
(display_gdb_prompt): Call gdb_rl_callback_handler_remove and
gdb_rl_callback_handler_install instead of
rl_callback_handler_remove and rl_callback_handler_install.
(gdb_disable_readline): Call gdb_rl_callback_handler_remove
instead of rl_callback_handler_remove.
* event-top.h (gdb_rl_callback_handler_remove)
(gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): New declarations.
* infrun.c (reinstall_readline_callback_handler_cleanup): New
cleanup function.
(fetch_inferior_event): Install it.
* top.c (gdb_readline_wrapper_line) Call
gdb_rl_callback_handler_remove instead of
rl_callback_handler_remove.
(gdb_readline_wrapper_cleanup): Don't call
rl_callback_handler_install.

gdb/testsuite/
2014-10-29  Pedro Alves  <palves@redhat.com>

PR python/17372
* gdb.python/python.exp: Test a multi-line command that spawns
interactive Python.
* gdb.base/multi-line-starts-subshell.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

PR gdb/17471: Repeating a background command makes it foreground

When we repeat a command, by just pressing <ret>, the input from the
previous command is reused for the new command invocation.

When an execution command strips the "&" out of its incoming argument
string, to detect background execution, we poke a '\0' directly to the
incoming argument string.

Combine both, and a repeat of a background command loses the "&".

This is actually only visible if args other than "&" are specified
(e.g., "c 1&" or "next 2&" or "c -a&"), as in the special case of "&"
alone (e.g. "c&") doesn't actually clobber the incoming string.

Fix this by making strip_bg_char return a new string instead of poking
a hole in the input string.

New test included.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17471
* infcmd.c (strip_bg_char): Change prototype and rewrite.  Now
returns a copy of the input.
(run_command_1, continue_command, step_1, jump_command)
(signal_command, until_command, advance_command, finish_command)
(attach_command): Adjust and install a cleanup to free the
stripped args.

gdb/testsuite/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17471
* gdb.base/bg-execution-repeat.c: New file.
* gdb.base/bg-execution-repeat.exp: New file.

PR gdb/17300: Input after "c -a" crashes readline/GDB

If all threads in the target were already running when the user does
"c -a", nothing puts the inferior's terminal settings in effect and
removes stdin from the event loop, which we must when running a
foreground command.  The result is that user input afterwards crashes
readline/gdb:

 (gdb) start
 Temporary breakpoint 1 at 0x4005d4: file continue-all-already-running.c, line 23.
 Starting program: continue-all-already-running

 Temporary breakpoint 1, main () at continue-all-already-running.c:23
 23        sleep (10);
 (gdb) c -a&
 Continuing.
 (gdb) c -a
 Continuing.
 p 1
 readline: readline_callback_read_char() called with no handler!
 Aborted (core dumped)
 $

Backtrace:

 Program received signal SIGABRT, Aborted.
 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
 (top-gdb) p 1
 $1 = 1
 (top-gdb) bt
 #0  0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 #1  0x0000003b36a36f68 in __GI_abort () at abort.c:89
 #2  0x0000000000784aa9 in rl_callback_read_char () at readline/callback.c:116
 #3  0x0000000000619181 in rl_callback_read_char_wrapper (client_data=0x0) at gdb/event-top.c:167
 #4  0x0000000000619557 in stdin_event_handler (error=0, client_data=0x0) at gdb/event-top.c:373
 #5  0x000000000061814a in handle_file_event (data=...) at gdb/event-loop.c:763
 #6  0x0000000000617631 in process_event () at gdb/event-loop.c:340
 #7  0x00000000006176f8 in gdb_do_one_event () at gdb/event-loop.c:404
 #8  0x0000000000617748 in start_event_loop () at gdb/event-loop.c:429
 #9  0x00000000006191b3 in cli_command_loop (data=0x0) at gdb/event-top.c:182
 #10 0x000000000060f538 in current_interp_command_loop () at gdb/interps.c:318
 #11 0x0000000000610701 in captured_command_loop (data=0x0) at gdb/main.c:323
 #12 0x000000000060c3f5 in catch_errors (func=0x6106e6 <captured_command_loop>, func_args=0x0, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
     at gdb/exceptions.c:237
 #13 0x0000000000611bff in captured_main (data=0x7fffffffd780) at gdb/main.c:1151
 #14 0x000000000060c3f5 in catch_errors (func=0x610afe <captured_main>, func_args=0x7fffffffd780, errstring=0x9002c1 "", mask=RETURN_MASK_ALL)
     at gdb/exceptions.c:237
 #15 0x0000000000611c28 in gdb_main (args=0x7fffffffd780) at gdb/main.c:1159
 #16 0x000000000045ef97 in main (argc=5, argv=0x7fffffffd888) at gdb/gdb.c:32
 (top-gdb)

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17300
* infcmd.c (continue_1): If continuing all threads in the
foreground, make sure the inferior's terminal settings are put in
effect.

gdb/testsuite/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17300
* gdb.base/continue-all-already-running.c: New file.
* gdb.base/continue-all-already-running.exp: New file.

PR gdb/17472: With annotations, input while executing in the foreground crashes readline/GDB

Jan caught an intermittent GDB crash with the annota1.exp test:

 Starting program: .../gdb/testsuite/gdb.base/annota1 ^M
 [...]
 FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
 [...]
 readline: readline_callback_read_char() called with no handler!^M
 ERROR: Process no longer exists

All we need to is to continue the inferior in the foreground, and type
a command while the inferior is running.  E.g.:

 (gdb) set annotate 2

 ▒▒pre-prompt
 (gdb)
 ▒▒prompt
 c

 ▒▒post-prompt
 Continuing.

 ▒▒starting

 ▒▒frames-invalid

 *inferior is running now*

 p 1<ret>

 readline: readline_callback_read_char() called with no handler!
 Aborted (core dumped)
 $

When we run a foreground execution command we call
target_terminal_inferior to stop GDB from processing input, and to put
the inferior's terminal settings in effect.  Then we tell readline to
hide the prompt with display_gdb_prompt, which clears readline's input
callback too.  When the target stops, we call target_terminal_ours,
which re-installs stdin in the event loop, and then we redisplay the
prompt, reinstalling the readline callbacks.

However, when annotations are in effect, the "frames-invalid"
annotation code calls target_terminal_ours after 'resume' had already
called target_terminal_inferior:

 (top-gdb) bt
 #0  0x000000000056b82f in annotate_frames_invalid () at gdb/annotate.c:219
 #1  0x000000000072e6cc in reinit_frame_cache () at gdb/frame.c:1705
 #2  0x0000000000594bb9 in registers_changed_ptid (ptid=...) at gdb/regcache.c:612
 #3  0x000000000064cca1 in target_resume (ptid=..., step=1, signal=GDB_SIGNAL_0) at gdb/target.c:2136
 #4  0x00000000005f57af in resume (step=1, sig=GDB_SIGNAL_0) at gdb/infrun.c:2263
 #5  0x00000000005f6051 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=1) at gdb/infrun.c:2613

And then once we hide the prompt and remove readline's input handler
callback, we're in a bad state.  We end up with the target running
supposedly in the foreground, but with stdin still installed on the
event loop.  Any input then calls into readline, which aborts because
no rl_linefunc callback handler is installed:

 Program received signal SIGABRT, Aborted.
 0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 56        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

 (top-gdb) bt
 #0  0x0000003b36a35877 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 #1  0x0000003b36a36f68 in __GI_abort () at abort.c:89
 During symbol reading, debug info gives source 9 included from file at zero line 0.
 During symbol reading, debug info gives command-line macro definition with non-zero line 19: _STDC_PREDEF_H 1.
 #2  0x0000000000784a25 in rl_callback_read_char () at src/readline/callback.c:116
 #3  0x0000000000619111 in rl_callback_read_char_wrapper (client_data=0x0) at src/gdb/event-top.c:167
 #4  0x00000000006194e7 in stdin_event_handler (error=0, client_data=0x0) at src/gdb/event-top.c:373
 #5  0x00000000006180da in handle_file_event (data=...) at src/gdb/event-loop.c:763
 #6  0x00000000006175c1 in process_event () at src/gdb/event-loop.c:340
 #7  0x0000000000617688 in gdb_do_one_event () at src/gdb/event-loop.c:404
 #8  0x00000000006176d8 in start_event_loop () at src/gdb/event-loop.c:429
 #9  0x0000000000619143 in cli_command_loop (data=0x0) at src/gdb/event-top.c:182
 #10 0x000000000060f4c8 in current_interp_command_loop () at src/gdb/interps.c:318
 #11 0x0000000000610691 in captured_command_loop (data=0x0) at src/gdb/main.c:323
 #12 0x000000000060c385 in catch_errors (func=0x610676 <captured_command_loop>, func_args=0x0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
     at src/gdb/exceptions.c:237
 #13 0x0000000000611b8f in captured_main (data=0x7fffffffd7b0) at src/gdb/main.c:1151
 #14 0x000000000060c385 in catch_errors (func=0x610a8e <captured_main>, func_args=0x7fffffffd7b0, errstring=0x900241 "", mask=RETURN_MASK_ALL)
     at src/gdb/exceptions.c:237
 #15 0x0000000000611bb8 in gdb_main (args=0x7fffffffd7b0) at src/gdb/main.c:1159
 #16 0x000000000045ef57 in main (argc=3, argv=0x7fffffffd8b8) at src/gdb/gdb.c:32

The fix is to make the annotation code call target_terminal_inferior
again after printing, if the inferior's settings were in effect.

While at it, when we're doing output only, instead of
target_terminal_ours, we should call target_terminal_ours_for_output.
The latter doesn't actually remove stdin from the event loop, and also
leaves SIGINT forwarded to the target.

New test included.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17472
* annotate.c (annotate_breakpoints_invalid): Use
target_terminal_our_for_output instead of target_terminal_ours.
Give back the terminal to the target.
(annotate_frames_invalid): Likewise.

gdb/testsuite/
2014-10-17  Pedro Alves  <palves@redhat.com>

PR gdb/17472
* gdb.base/annota-input-while-running.c: New file.
* gdb.base/annota-input-while-running.exp: New file.

Make common code handle target_terminal_* idempotency

I found a place that should be giving back the terminal to the target,
but only if the target was already owning it.  So I need to add a
getter for who owns the terminal.

The trouble is that several places/target have their own globals to
track this state:

 - inflow.c:terminal_is_ours
 - remote.c:remote_async_terminal_ours_p
 - linux-nat.c:async_terminal_is_ours
 - go32-nat.c:terminal_is_ours

While one might think of adding a new target_ops method to query this,
conceptually, this state isn't really part of a particular target_ops.
Considering multi-target, the core shouldn't have to ask all targets
to know whether it's GDB that owns the terminal.  There's only one GDB
(or rather, only one top level interpreter).

So what this comment does is add a new global that is tracked by the
core instead.  A subsequent pass may later remove the other globals.

Tested on x86_64 Fedora 20, native and gdbserver.

gdb/
2014-10-17  Pedro Alves  <palves@redhat.com>

* target.c (enum terminal_state): New enum.
(terminal_state): New global.
(target_terminal_init): New function.
(target_terminal_inferior): Skip if inferior already owns the
terminal.
(target_terminal_ours, target_terminal_ours_for_output): New
functions.
* target.h (target_terminal_init): Convert to function prototype.
(target_terminal_ours_for_output): Convert to function prototype
and tweak comment.
(target_terminal_ours): Convert to function prototype and tweak
comment.
* windows-nat.c (do_initial_windows_stuff): Call
target_terminal_init instead of child_terminal_init_with_pgrp.

Automatic date update in version.in

Automatic date update in version.in