This commit moves the inclusion of ptid.h to common-defs.h and removes
all other inclusions.
gdb/
2014-08-07 Gary Benson <gbenson@redhat.com>
* common/common-defs.h: Include ptid.h.
* defs.h: Do not include ptid.h.
* inferior.h: Likewise.
* infrun.h: Likewise.
* nat/linux-btrace.h: Likewise.
* nat/linux-osdata.h: Likewise.
* target/waitstatus.h: Likewise.
gdb/gdbserver/
2014-08-07 Gary Benson <gbenson@redhat.com>
* server.h: Do not include ptid.h.
* notif.h: Likewise.
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
Ignoring expected and desired differences like whether the prompt is
output after *stoppped records, GDB MI output is still different in
sync and async modes.
In sync mode, when a CLI execution command is entered, the "reason"
field is missing in the *stopped async record. And in async mode, for
some events, like program exits, the corresponding CLI output is
missing in the CLI channel.
Vis, diff between sync vs async modes:
run
^running
*running,thread-id="1"
(gdb)
...
- ~"[Inferior 1 (process 15882) exited normally]\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
- *stopped
+ *stopped,reason="exited-normally"
si
...
(gdb)
~"0x000000000045e033\t29\t memset (&args, 0, sizeof args);\n"
- *stopped,frame=...,thread-id="1",stopped-threads="all",core="0"
+ *stopped,reason="end-stepping-range",frame=...,thread-id="1",stopped-threads="all",core="0"
(gdb)
In addition, in both cases, when a MI execution command is entered,
and a breakpoint triggers, the event is sent to the console too. But
some events like program exits have the CLI output missing in the CLI
channel:
-exec-run
^running
*running,thread-id="1"
(gdb)
...
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
- *stopped
+ *stopped,reason="exited-normally"
We'll want to make background commands always possible by default.
IOW, make target-async be the default. But, in order to do that,
we'll need to emulate MI sync on top of an async target. That means
we'll have yet another combination to care for in the testsuite.
Rather than making the testsuite cope with all these differences, I
thought it better to just fix GDB to always have the complete output,
no matter whether it's in sync or async mode.
This is all related to interpreter-exec, and the corresponding uiout
switching. (Typing a CLI command directly in MI is shorthand for
running it through -interpreter-exec console.)
In sync mode, when a CLI command is active, normal_stop is called when
the current interpreter and uiout are CLI's. So print_XXX_reason
prints the stop reason to CLI uiout (only), and we don't show it in
MI.
In async mode the stop event is processed when we're back in the MI
interpreter, so the stop reason is printed directly to the MI uiout.
Fix this by making run control event printing roughly independent of
whatever is the current interpreter or uiout. That is, move these
prints to interpreter observers, that know whether to print or be
quiet, and if printing, which uiout to print to. In the case of the
console/tui interpreters, only print if the top interpreter. For MI,
always print.
Breakpoint hits / normal stops are already handled similarly -- MI has
a normal_stop observer that prints the event to both MI and the CLI,
though that could be cleaned up further in the direction of this
patch.
This also makes all of:
(gdb) foo
and
(gdb) interpreter-exec MI "-exec-foo"
and
(gdb)
-exec-foo
and
(gdb)
-interpreter-exec console "foo"
print as expected.
Tested on x86_64 Fedora 20, sync and async modes.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* cli/cli-interp.c: Include infrun.h and observer.h.
(cli_uiout, cli_interp): New globals.
(cli_on_signal_received, cli_on_end_stepping_range)
(cli_on_signal_exited, cli_on_exited, cli_on_no_history): New
functions.
(cli_interpreter_init): Install them as 'end_stepping_range',
'signal_received' 'signal_exited', 'exited' and 'no_history'
observers.
(_initialize_cli_interp): Remove cli_interp local.
* infrun.c (handle_inferior_event): Call the several stop reason
observers instead of printing the stop reason directly.
(end_stepping_range): New function.
(print_end_stepping_range_reason, print_signal_exited_reason)
(print_exited_reason, print_signal_received_reason)
(print_no_history_reason): Make static, and add an uiout
parameter. Print to that instead of to CURRENT_UIOUT.
* infrun.h (print_end_stepping_range_reason)
(print_signal_exited_reason, print_exited_reason)
(print_signal_received_reason print_no_history_reason): New
declarations.
* mi/mi-common.h (struct mi_interp): Rename 'uiout' field to
'mi_uiout'.
<cli_uiout>: New field.
* mi/mi-interp.c (mi_interpreter_init): Adjust. Create the new
uiout for CLI output. Install 'signal_received',
'end_stepping_range', 'signal_exited', 'exited' and 'no_history'
observers.
(find_mi_interpreter, mi_interp_data, mi_on_signal_received)
(mi_on_end_stepping_range, mi_on_signal_exited, mi_on_exited)
(mi_on_no_history): New functions.
(ui_out_free_cleanup): Delete function.
(mi_on_normal_stop): Don't allocate a new uiout for CLI output,
instead use the one already stored in the MI interpreter data.
(mi_ui_out): Adjust.
* tui/tui-interp.c: Include infrun.h and observer.h.
(tui_interp): New global.
(tui_on_signal_received, tui_on_end_stepping_range)
(tui_on_signal_exited, tui_on_exited)
(tui_on_no_history): New functions.
(tui_init): Install them as 'end_stepping_range',
'signal_received' 'signal_exited', 'exited' and 'no_history'
observers.
(_initialize_tui_interp): Delete tui_interp local.
gdb/doc/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* observer.texi (signal_received, end_stepping_range)
(signal_exited, exited, no_history): New observer subjects.
gdb/testsuite/
2014-05-29 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp: Always expect "end-stepping-range" stop
reason, even in sync mode.
Move infrun.c declarations out of inferior.h to a new infrun.h file.
Tested by building on:
i686-w64-mingw32, enable-targets=all
x86_64-linux, enable-targets=all
i586-pc-msdosdjgpp
And also grepped the whole tree for each symbol moved to find where
infrun.h might be necessary.
gdb/
2014-05-22 Pedro Alves <palves@redhat.com>
* inferior.h (debug_infrun, debug_displaced, stop_on_solib_events)
(sync_execution, sched_multi, step_stop_if_no_debug, non_stop)
(disable_randomization, enum exec_direction_kind)
(execution_direction, stop_registers, start_remote)
(clear_proceed_status, proceed, resume, user_visible_resume_ptid)
(wait_for_inferior, normal_stop, get_last_target_status)
(prepare_for_detach, fetch_inferior_event, init_wait_for_inferior)
(insert_step_resume_breakpoint_at_sal)
(follow_inferior_reset_breakpoints, stepping_past_instruction_at)
(set_step_info, print_stop_event, signal_stop_state)
(signal_print_state, signal_pass_state, signal_stop_update)
(signal_print_update, signal_pass_update)
(update_signals_program_target, clear_exit_convenience_vars)
(displaced_step_dump_bytes, update_observer_mode)
(signal_catch_update, gdb_signal_from_command): Move
declarations ...
* infrun.h: ... to this new file.
* amd64-tdep.c: Include infrun.h.
* annotate.c: Include infrun.h.
* arch-utils.c: Include infrun.h.
* arm-linux-tdep.c: Include infrun.h.
* arm-tdep.c: Include infrun.h.
* break-catch-sig.c: Include infrun.h.
* breakpoint.c: Include infrun.h.
* common/agent.c: Include infrun.h instead of inferior.h.
* corelow.c: Include infrun.h.
* event-top.c: Include infrun.h.
* go32-nat.c: Include infrun.h.
* i386-tdep.c: Include infrun.h.
* inf-loop.c: Include infrun.h.
* infcall.c: Include infrun.h.
* infcmd.c: Include infrun.h.
* infrun.c: Include infrun.h.
* linux-fork.c: Include infrun.h.
* linux-nat.c: Include infrun.h.
* linux-thread-db.c: Include infrun.h.
* monitor.c: Include infrun.h.
* nto-tdep.c: Include infrun.h.
* procfs.c: Include infrun.h.
* record-btrace.c: Include infrun.h.
* record-full.c: Include infrun.h.
* remote-m32r-sdi.c: Include infrun.h.
* remote-mips.c: Include infrun.h.
* remote-notif.c: Include infrun.h.
* remote-sim.c: Include infrun.h.
* remote.c: Include infrun.h.
* reverse.c: Include infrun.h.
* rs6000-tdep.c: Include infrun.h.
* s390-linux-tdep.c: Include infrun.h.
* solib-irix.c: Include infrun.h.
* solib-osf.c: Include infrun.h.
* solib-svr4.c: Include infrun.h.
* target.c: Include infrun.h.
* top.c: Include infrun.h.
* windows-nat.c: Include infrun.h.
* mi/mi-interp.c: Include infrun.h.
* mi/mi-main.c: Include infrun.h.
* python/py-threadevent.c: Include infrun.h.
Gary Benson
Pedro Alves