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.
This patch is to add ptid into dummy_frame and extend frame_id to
dummy_frame_id (which has a ptid field). With this change, GDB uses
dummy_frame_id (thread ptid and frame_id) to find the dummy frames.
Currently, dummy frames are looked up by frame_id, which isn't
accurate in non-stop or multi-process mode. The test case
gdb.multi/dummy-frame-restore.exp shows the problem and this patch can
fix it.
Test dummy-frame-restore.exp makes two inferiors stop at
different functions, say, inferior 1 stops at f1 while inferior 2
stops at f2. Set a breakpoint to a function, do the inferior call
in two inferiors, and GDB has two dummy frames of the same frame_id.
When the inferior call is finished, GDB will look up a dummy frame
from its stack/list and restore the inferior's regcache. Two
inferiors are finished in different orders, the inferiors' states are
restored differently, which is wrong. Running dummy-frame-restore.exp
under un-patched GDB, we'll get two fails:
FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 2
FAIL: gdb.multi/dummy-frame-restore.exp: inf 2 first: after infcall: bt in inferior 1
With this patch applied, GDB will choose the correct dummy_frame to
restore for a given inferior, because ptid is considered when looking up
dummy frames. Two fails above are fixed.
Regression tested on x86_64-linux, both native and gdbserver.
gdb:
2014-06-27 Yao Qi <yao@codesourcery.com>
* breakpoint.c (check_longjmp_breakpoint_for_call_dummy):
Change parameter type to 'struct thread_info *'. Caller
updated.
* breakpoint.h (check_longjmp_breakpoint_for_call_dummy):
Update declaration.
* dummy-frame.c (struct dummy_frame_id): New.
(dummy_frame_id_eq): New function.
(struct dummy_frame) <id>: Change its type to 'struct
dummy_frame_id'.
(dummy_frame_push): Add parameter ptid and save it in
dummy_frame_id.
(pop_dummy_frame_bpt): Use ptid of dummy_frame instead of
inferior_ptid.
(pop_dummy_frame): Assert that the ptid of dummy_frame equals
to inferior_ptid.
(lookup_dummy_frame): Change parameter type to 'struct
dummy_frame_id *'. Callers updated. Call dummy_frame_id_eq
instead of frame_id_eq.
(dummy_frame_pop): Add parameter ptid. Callers updated.
Update comments. Compose dummy_frame_id and pass it to
lookup_dummy_frame.
(dummy_frame_discard): Add parameter ptid.
(dummy_frame_sniffer): Compose dummy_frame_id and call
dummy_frame_id_eq instead of frame_id_eq.
(fprint_dummy_frames): Print ptid.
* dummy-frame.h: Remove comments.
(dummy_frame_push): Add ptid in declaration.
(dummy_frame_pop, dummy_frame_discard): Likewise.
gdb/testsuite:
2014-06-27 Yao Qi <yao@codesourcery.com>
* gdb.multi/dummy-frame-restore.exp: New.
* gdb.multi/dummy-frame-restore.c: New.
gdb/doc:
2014-06-27 Yao Qi <yao@codesourcery.com>
* gdb.texinfo (Maintenance Commands): Update the output of
'maint print dummy-frames' command.
When I read the code, I happen to see this:
signal_pass = (unsigned char *)
xmalloc (sizeof (signal_program[0]) * numsigs);
^^^^^^^^^^^^^^
It is a typo, and this patch is to fix it.
gdb:
2014-06-26 Yao Qi <yao@codesourcery.com>
* infrun.c (_initialize_infrun): Replace "signal_program[0]"
with "signal_pass[0]" in the initialization of signal_pass.
Running gdb.threads/thread-execl.exp with scheduler-locking set to
"step" reveals a problem:
(gdb) next^M
[Thread 0x7ffff7fda700 (LWP 27168) exited]^M
[New LWP 27168]^M
[Thread 0x7ffff74ee700 (LWP 27174) exited]^M
process 27168 is executing new program: /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.threads/thread-execl^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
infrun.c:5225: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) FAIL: gdb.threads/thread-execl.exp: schedlock step: get to main in new image (GDB internal error)
The assertion is correct. The issue is that GDB is mistakenly trying
to switch back to an exited thread, that was previously stepping when
it exited. This is exactly the sort of thing the test wants to make
sure doesn't happen:
# Now set a breakpoint at `main', and step over the execl call. The
# breakpoint at main should be reached. GDB should not try to revert
# back to the old thread from the old image and resume stepping it
We don't see this bug with schedlock off only because a different
sequence of events makes GDB manage to delete the thread instead of
marking it exited.
This particular internal error can be fixed by making the loop over
all threads in switch_back_to_stepped_thread skip exited threads.
But, looking over other ALL_THREADS users, all either can or should be
skipping exited threads too. So for simplicity, this patch replaces
ALL_THREADS with a new macro that skips exited threads itself, and
updates everything to use it.
Tested on x86_64 Fedora 20.
gdb/
2014-06-19 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_THREADS): Delete.
(ALL_NON_EXITED_THREADS): New macro.
* btrace.c (btrace_free_objfile): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* infrun.c (find_thread_needs_step_over)
(switch_back_to_stepped_thread): Use ALL_NON_EXITED_THREADS
instead of ALL_THREADS.
* record-btrace.c (record_btrace_open)
(record_btrace_stop_recording, record_btrace_close)
(record_btrace_is_replaying, record_btrace_resume)
(record_btrace_find_thread_to_move, record_btrace_wait): Likewise.
* remote.c (append_pending_thread_resumptions): Likewise.
* thread.c (thread_apply_all_command): Likewise.
gdb/testsuite/
2014-06-19 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): New procedure, factored
out from ...
(top level): ... here. Iterate running tests under different
scheduler-locking settings.
Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to
"child" and detach-on-fork set to "off", stepping or running past the fork
call results in the child process running to completion, when it should
just finish the single step. In addition, the breakpoint is not removed
from the parent process, so if it is resumed it receives a SIGTRAP.
Cause:
No matter what the setting for detach-on-fork, when stepping past a fork,
the single-step breakpoint (step_resume_breakpoint) is not handled
correctly in the parent. The SR breakpoint is cloned for the child
process, but before the clone is associated with the child it is treated as
a duplicate of the original, associated wth the parent. This results in
the insertion state of the original SR breakpoint and the clone being
"swapped" by breakpoint.c:update_global_location_list, so that the clone is
marked as inserted.
In the case where the parent is not detached, the two breakpoints remain in
that state. The breakpoint is never inserted in the child, because
although the cloned SR breakpoint is associated with the child, it is
marked as inserted. When the child is resumed, it runs to completion. The
breakpoint is never removed from the parent, so that if it is resumed after
the child exits, it gets a SIGTRAP.
Here is the sequence of events:
1) handle_inferior_event: FORK event is recognized.
2) handle_inferior_event: detach_breakpoints removes all breakpoints
from the child.
3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure
is to call update_global_location_list, which swaps the insertion state of
the original and cloned SR breakpoints as part of ensuring that duplicate
breakpoints are only inserted once. At this point the original SR
breakpoint is not marked as inserted, and the clone is. The breakpoint is
actually inserted in the parent but not the child.
4) follow_fork: the original breakpoint is deleted by calling
delete_step_resume_breakpoint. Since the original is not marked as
inserted, the actual breakpoint remains in the parent process.
update_global_location_list is called again as part of the deletion. The
clone is still associated with the parent, but since it is marked as
enabled and inserted, the breakpoint is left in the parent.
5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be
removed from the parent in target_detach, based on the cloned breakpoint
still associated with the parent. Then the clone is no longer marked as
inserted. In follow_inferior_reset_breakpoints the clone is associated
with the child, and can be inserted.
If detach-on-fork is 'off', the actual breakpoint in the parent is never
removed (although the breakpoint had been deleted from the list). Since
the clone continues to be marked 'inserted', the SR breakpoint is never
inserted in the child.
Fix:
Set the cloned breakpoint as disabled from the moment it is created. This
is done by modifying clone_momentary_breakpoint to take an additional
argument, LOC_ENABLED, which is used as the value of the
bp_location->enabled member. The clone must be disabled at that point
because clone_momentary_breakpoint calls update_global_location_list, which
will swap treat the clone as a duplicate of the original breakpoint if it
is enabled.
All the calls to clone_momentary_breakpoint had to be modified to pass '1'
or '0'. I looked at implementing an enum for the enabled member, but
concluded that readability would suffer because there are so many places it
is used as a boolean, e.g. "if (bl->enabled)".
In follow_inferior_reset_breakpoints the clone is set to enabled once it
has been associated with the child process. With this, the bp_location
'inserted' member is maintained correctly throughout the follow-fork
procedure and the behavior is as expected.
The same treatment is given to the exception_resume_breakpoint when
following a fork.
Testing:
Ran 'make check' on Linux x64.
Along with the fix above, the coverage of the follow-fork test
gdb.base/foll-fork.exp was expanded to:
1) cover all the combinations of values for
follow-fork-mode and detach-on-fork
2) make sure that both user breakpoints and
single-step breakpoints are propagated
correctly to the child
3) check that the inferior list has the
expected contents after following the fork.
4) check that unfollowed, undetached inferiors
can be resumed.
gdb/
2014-06-18 Don Breazeal <donb@codesourcery.com>
* breakpoint.c (set_longjmp_breakpoint): Call
momentary_breakpoint_from_master with additional argument.
(set_longjmp_breakpoint_for_call_dummy): Call
momentary_breakpoint_from_master with additional argument.
(set_std_terminate_breakpoint): Call
momentary_breakpoint_from_master with additional argument.
(momentary_breakpoint_from_master): Add argument to function
definition and use it to initialize structure member flag.
(clone_momentary_breakpoint): Call
momentary_breakpoint_from_master with additional argument.
* infrun.c (follow_inferior_reset_breakpoints): Clear structure
member flags set in momentary_breakpoint_from_master.
gdb/testsuite/
2014-06-18 Don Breazeal <donb@codesourcery.com>
* gdb.base/foll-fork.exp (default_fork_parent_follow):
Deleted procedure.
(explicit_fork_parent_follow): Deleted procedure.
(explicit_fork_child_follow): Deleted procedure.
(test_follow_fork): New procedure.
(do_fork_tests): Replace calls to deleted procedures with
calls to test_follow_fork and reset GDB for subsequent
procedure calls.
branch showed some extra assertions I have in place triggering. Turns
out my previous change to 'resume' was incomplete, and we mishandle
the 'hw_step' / 'step' variable pair. (I swear I had fixed this, but
I guess I lost that in some local branch...)
Tested on x86_64 Fedora 20.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
* infrun.c (resume): Rename local 'hw_step' to 'entry_step'
and make it const. When a single-step decays to a continue,
clear 'step', not 'hw_step'. Pass whether the caller wanted
to step to user_visible_resume_ptid, not what we ask the
target to do.
- all end_stepping_range callers also set stop_step.
- all places that set stop_step call end_stepping_range and
stop_waiting too.
IOW, all places where we handle "end stepping range" do:
ecs->event_thread->control.stop_step = 1;
end_stepping_range ();
stop_waiting (ecs);
Factor that out into end_stepping_range itself.
Tested on x86_64 Fedora 20.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test, handle_step_into_function)
(handle_step_into_function_backward): Adjust.
Don't set the even thread's stop_step and call stop_waiting before
calling end_stepping_range. Instead do that ...
(end_stepping_range): ... here. Take an ecs pointer parameter.
stop_stepping is called even when we weren't stepping. It's job really is:
static void
stop_waiting (struct execution_control_state *ecs)
{
...
/* Let callers know we don't want to wait for the inferior anymore. */
ecs->wait_some_more = 0;
}
So rename it for clarity.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
* infrun.c (stop_stepping): Rename to ...
(stop_waiting): ... this.
(proceed): Update comment.
(process_event_stop_test, handle_inferior_event)
(handle_signal_stop, handle_step_into_function)
(handle_step_into_function_backward): Update.
This finally makes background execution commands possible by default.
However, in order to do that, there's one last thing we need to do --
we need to separate the MI and target notions of "async". Unlike the
CLI, where the user explicitly requests foreground vs background
execution in the execution command itself (c vs c&), MI chose to treat
"set target-async" specially -- setting it changes the default
behavior of execution commands.
So, we can't simply "set target-async" default to on, as that would
affect MI frontends. Instead we have to make the setting MI-specific,
and teach MI about sync commands on top of an async target.
Because the "target" word in "set target-async" ends up as a potential
source of confusion, the patch adds a "set mi-async" option, and makes
"set target-async" a deprecated alias.
Rather than make the targets always async, this patch introduces a new
"maint set target-async" option so that the GDB developer can control
whether the target is async. This makes it simpler to debug issues
arising only in the synchronous mode; important because sync mode
seems unlikely to go away.
Unlike in previous revisions, "set target-async" does not affect this
new maint parameter. The rationale for this is that then one can
easily run the test suite in the "maint set target-async off" mode and
have tests that enable mi-async fail just like they fail on
non-async-capable targets. This emulation is exactly the point of the
maint option.
I had asked Tom in a previous iteration to split the actual change of
the target async default to a separate patch, but it turns out that
that is quite awkward in this version of the patch, because with MI
async and target async decoupled (unlike in previous versions), if we
don't flip the default at the same time, then just "set target-async
on" alone never actually manages to do anything. It's best to not
have that transitory state in the tree.
Given "set target-async on" now only has effect for MI, the patch goes
through the testsuite removing it from non-MI tests. MI tests are
adjusted to use the new and less confusing "mi-async" spelling.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* NEWS: Mention "maint set target-async", "set mi-async", and that
background execution commands are now always available.
* target.h (target_async_permitted): Update comment.
* target.c (target_async_permitted, target_async_permitted_1):
Default to 1.
(set_target_async_command): Rename to ...
(maint_set_target_async_command): ... this.
(show_target_async_command): Rename to ...
(maint_show_target_async_command): ... this.
(_initialize_target): Adjust.
* infcmd.c (prepare_execution_command): Make extern.
* inferior.h (prepare_execution_command): Declare.
* infrun.c (set_observer_mode): Leave target async alone.
* mi/mi-interp.c (mi_interpreter_init): Install
mi_on_sync_execution_done as sync_execution_done observer.
(mi_on_sync_execution_done): New function.
(mi_execute_command_input_handler): Don't print the prompt if we
just started a synchronous command with an async target.
(mi_on_resume): Check sync_execution before printing prompt.
* mi/mi-main.h (mi_async_p): Declare.
* mi/mi-main.c: Include gdbcmd.h.
(mi_async_p): New function.
(mi_async, mi_async_1): New globals.
(set_mi_async_command, show_mi_async_command, mi_async): New
functions.
(exec_continue): Call prepare_execution_command.
(run_one_inferior, mi_cmd_exec_run, mi_cmd_list_target_features)
(mi_execute_async_cli_command): Use mi_async_p.
(_initialize_mi_main): Install "set mi-async". Make
"target-async" a deprecated alias.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Non-Stop Mode): Remove "set target-async 1"
from example.
(Asynchronous and non-stop modes): Document '-gdb-set mi-async'.
Mention that target-async is now deprecated.
(Maintenance Commands): Document maint set/show target-async.
2014-05-29 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* gdb.base/async-shell.exp: Don't enable target-async.
* gdb.base/async.exp
* gdb.base/corefile.exp (corefile_test_attach): Remove 'async'
parameter. Adjust.
(top level): Don't test with "target-async".
* gdb.base/dprintf-non-stop.exp: Don't enable target-async.
* gdb.base/gdb-sigterm.exp: Don't test with "target-async".
* gdb.base/inferior-died.exp: Don't enable target-async.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.mi/mi-async.exp: Use "mi-async" instead of "target-async".
* gdb.mi/mi-nonstop-exit.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-ns-stale-regcache.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.mi/mi-nsmoribund.exp: Likewise.
* gdb.mi/mi-nsthrexec.exp: Likewise.
* gdb.mi/mi-watch-nonstop.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Adjust comment.
* gdb.python/py-evsignal.exp: Don't enable target-async.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.reverse/break-precsave.exp: Don't test with "target-async".
* gdb.server/solib-list.exp: Don't enable target-async.
* gdb.threads/thread-specific-bp.exp: Likewise.
* lib/mi-support.exp: Adjust to use mi-async.
Enabling target-async by default will require implementing sync
execution on top of an async target, much like foreground command are
implemented on the CLI in async mode.
In order to do that, we will need better control of when to print the
MI prompt. Currently the interp->display_prompt_p hook is all we
have, and MI just always returns false, meaning, make
display_gdb_prompt a no-op. We'll need to be able to know to print
the MI prompt in some of the conditions that display_gdb_prompt is
called from the core, but not all.
This is all a litte twisted currently. As we can see,
display_gdb_prompt is really CLI specific, so make the console
interpreters (console/tui) themselves call it. To be able to do that,
and add a few different observers that the interpreters can use to
distinguish when or why the the prompt is being printed:
#1 - one called whenever a command is cancelled due to an error.
#2 - another for when a foreground command just finished.
In both cases, CLI wants to print the prompt, while MI doesn't.
MI will want to print the prompt in the second case when in a special
MI mode.
The display_gdb_prompt call in interp_set made me pause. The comment
there reads:
/* Finally, put up the new prompt to show that we are indeed here.
Also, display_gdb_prompt for the console does some readline magic
which is needed for the console interpreter, at least... */
But, that looks very much like a no-op to me currently:
- the MI interpreter always return false in the prompt hook, meaning
actually display no prompt.
- the interpreter used at that point is still quiet. And the
console/tui interpreters return false in the prompt hook if they're
quiet, meaning actually display no prompt.
The only remaining possible use would then be the readline magic. But
whatever that might have been, it's not reacheable today either,
because display_gdb_prompt returns early, before touching readline if
the interpreter returns false in the display_prompt_p hook.
Tested on x86_64 Fedora 20, sync and async modes.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_interpreter_display_prompt_p): Delete.
(_initialize_cli_interp): Adjust.
* event-loop.c: Include "observer.h".
(start_event_loop): Notify 'command_error' observers instead of
calling display_gdb_prompt. Remove FIXME comment.
* event-top.c (display_gdb_prompt): Remove call into the
interpreters.
* inf-loop.c: Include "observer.h".
(inferior_event_handler): Notify 'command_error' observers instead
of calling display_gdb_prompt.
* infrun.c (fetch_inferior_event): Notify 'sync_execution_done'
observers instead of calling display_gdb_prompt.
* interps.c (interp_set): Don't call display_gdb_prompt.
(current_interp_display_prompt_p): Delete.
* interps.h (interp_prompt_p): Delete declaration.
(interp_prompt_p_ftype): Delete.
(struct interp_procs) <prompt_proc_p>: Delete field.
(current_interp_display_prompt_p): Delete declaration.
* mi-interp.c (mi_interpreter_prompt_p): Delete.
(_initialize_mi_interp): Adjust.
* tui-interp.c (tui_init): Install 'sync_execution_done' and
'command_error' observers.
(tui_on_sync_execution_done, tui_on_command_error): New
functions.
(tui_display_prompt_p): Delete.
(_initialize_tui_interp): Adjust.
gdb/doc/
2014-05-29 Pedro Alves <palves@redhat.com>
* observer.texi (sync_execution_done, command_error): New
subjects.
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.
If one sets a breakpoint with a condition that involves calling a
function in the inferior, and then the condition evaluates false, GDB
outputs one *running event for each time the program hits the
breakpoint. E.g.,
$ gdb return-false -i=mi
(gdb)
start
...
(gdb)
b 14 if return_false ()
&"b 14 if return_false ()\n"
~"Breakpoint 2 at 0x4004eb: file return-false.c, line 14.\n"
...
^done
(gdb)
c
&"c\n"
~"Continuing.\n"
^running
*running,thread-id=(...)
(gdb)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
*running,thread-id=(...)
... repeat forever ...
An easy way a user can trip on this is with a dprintf with "set
dprintf-style call". In that case, a dprintf is just a breakpoint
that when hit GDB calls the printf function in the inferior, and then
resumes it, just like the case above.
If the breakpoint/dprintf is set in a loop, then these spurious events
can potentially slow down a frontend much, if it decides to refresh
its GUI whenever it sees this event (Eclipse is one such case).
When we run an infcall, we pretend we don't actually run the inferior.
This is already handled for the usual case of calling a function
directly from the CLI:
(gdb)
p return_false ()
&"p return_false ()\n"
~"$1 = 0"
~"\n"
^done
(gdb)
Note no *running, nor *stopped events. That's handled by:
static void
mi_on_resume (ptid_t ptid)
{
...
/* Suppress output while calling an inferior function. */
if (tp->control.in_infcall)
return;
and equivalent code on normal_stop.
However, in the cases of the PR, after finishing the infcall there's
one more resume, and mi_on_resume doesn't know that it should suppress
output then too, somehow.
The "running/stopped" state is a high level user/frontend state.
Internal stops are invisible to the frontend. If follows from that
that we should be setting the thread to running at a higher level
where we still know the set of threads the user _intends_ to resume.
Currently we mark a thread as running from within target_resume, a low
level target operation. As consequence, today, if we resume a
multi-threaded program while stopped at a breakpoint, we see this:
-exec-continue
^running
*running,thread-id="1"
(gdb)
*running,thread-id="all"
The first *running was GDB stepping over the breakpoint, and the
second is GDB finally resuming everything.
Between those two *running's, threads other than "1" still have their
state set to stopped. That's bogus -- in async mode, this opens a
tiny window between both resumes where the user might try to run
another execution command to threads other than thread 1, and very
much confuse GDB.
That is, the "step" below should fail the "step", complaining that the
thread is running:
(gdb) c -a &
(gdb) thread 2
(gdb) step
IOW, threads that GDB happens to not resume immediately (say, because
it needs to step over a breakpoint) shall still be marked as running.
Then, if we move marking threads as running to a higher layer,
decoupled from target_resume, plus skip marking threads as running
when running an infcall, the spurious *running events disappear,
because there will be no state transitions at all.
I think we might end up adding a new thread state -- THREAD_INFCALL or
some such, however since infcalls are always synchronous today, I
didn't find a need. There's no way to execute a CLI/MI command
directly from the prompt if some thread is running an infcall.
Tested on x86_64 Fedora 20.
gdb/
2014-05-29 Pedro Alves <palves@redhat.com>
PR PR15693
* infrun.c (resume): Determine how much to resume depending on
whether the caller wanted a step, not whether we can hardware step
the target. Mark all threads that we intend to run as running,
unless we're calling an inferior function.
(normal_stop): If the thread is running an infcall, don't finish
thread state.
* target.c (target_resume): Don't mark threads as running here.
gdb/testsuite/
2014-05-29 Pedro Alves <palves@redhat.com>
Hui Zhu <hui@codesourcery.com>
PR PR15693
* gdb.mi/mi-condbreak-call-thr-state-mt.c: New file.
* gdb.mi/mi-condbreak-call-thr-state-st.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.c: New file.
* gdb.mi/mi-condbreak-call-thr-state.exp: New file.
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.
A small cleanup - so we can call the print routine without affecting
--return-child-result.
gdb/
2014-05-22 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): Store the exit code for
--return-child-result here, instead of ...
(print_exited_reason): ... here.
The other part of PR gdb/13860 is about console execution commands in
MI getting their output half lost. E.g., take the finish command,
executed on a frontend's GDB console:
sync:
finish
&"finish\n"
~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n"
^running
*running,thread-id="1"
(gdb)
~"0x00000000004004d7 in foo () at stepinf.c:6\n"
~"6\t usleep (10);\n"
~"Value returned is $1 = 0\n"
*stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},thread-id="1",stopped-threads="all",core="1"
async:
finish
&"finish\n"
~"Run till exit from #0 usleep (useconds=10) at ../sysdeps/unix/sysv/linux/usleep.c:27\n"
^running
*running,thread-id="1"
(gdb)
*stopped,reason="function-finished",frame={addr="0x00000000004004d7",func="foo",args=[],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="6"},gdb-result-var="$1",return-value="0",thread-id="1",stopped-threads="all",core="0"
Note how all the "Value returned" etc. output is missing in async mode.
The same happens with e.g., catchpoints:
=breakpoint-modified,bkpt={number="1",type="catchpoint",disp="keep",enabled="y",what="22016",times="1"}
~"\nCatchpoint "
~"1 (forked process 22016), 0x0000003791cbd8a6 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131\n"
~"131\t pid = ARCH_FORK ();\n"
*stopped,reason="fork",disp="keep",bkptno="1",newpid="22016",frame={addr="0x0000003791cbd8a6",func="__libc_fork",args=[],file="../nptl/sysdeps/unix/sysv/linux/fork.c",fullname="/usr/src/debug/glibc-2.14-394-g8f3b1ff/nptl/sysdeps/unix/sysv/linux/fork.c",line="131"},thread-id="1",stopped-threads="all",core="0"
where all those ~ lines are missing in async mode, or just the "step"
current line indication:
s
&"s\n"
^running
*running,thread-id="all"
(gdb)
~"13\t foo ();\n"
*stopped,frame={addr="0x00000000004004ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffdd78"}],file="stepinf.c",fullname="/home/pedro/gdb/tests/stepinf.c",line="13"},thread-id="1",stopped-threads="all",core="3"
(gdb)
Or in the case of the PRs example, the "Stopped due to shared library
event" note:
start
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="21990"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="3"
(gdb)
IMO, if you're typing execution commands in a frontend's console, you
expect to see their output. Indeed it's what you get in sync mode. I
think async mode should do the same. Deciding what to mirror to the
console wrt to breakpoints and random stops gets messy real fast.
E.g., say "s" trips on a breakpoint. We'd clearly want to mirror the
event to the console in this case. But what about more complicated
cases like "s&; thread n; s&", and one of those steps spawning a new
thread, and that thread hitting a breakpoint? It's impossible in
general to track whether the thread had any relation to the commands
that had been executed. So I think we should just simplify and always
mirror breakpoints and random events to the console.
Notes:
- mi->out is the same as gdb_stdout when MI is the current
interpreter. I think that referring to that directly is cleaner.
An earlier revision of this patch made the changes that are now
done in mi_on_normal_stop directly in infrun.c:normal_stop, and so
not having an obvious place to put the new uiout by then, and not
wanting to abuse CLI's uiout, I made a temporary uiout when
necessary.
- Hopefuly the rest of the patch is more or less obvious given the
comments added.
Tested on x86_64 Fedora 20, no regressions.
2014-05-21 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdbthread.h (struct thread_control_state): New field
`command_interp'.
* infrun.c (follow_fork): Copy the new thread control field to the
child fork thread.
(clear_proceed_status_thread): Clear the new thread control field.
(proceed): Set the new thread control field.
* interps.h (command_interp): Declare.
* interps.c (command_interpreter): New global.
(command_interp): New function.
(interp_exec): Set `command_interpreter' while here.
* cli-out.c (cli_uiout_dtor): New function.
(cli_ui_out_impl): Install it.
* mi/mi-interp.c: Include cli-out.h.
(mi_cmd_interpreter_exec): Add comment.
(restore_current_uiout_cleanup): New function.
(ui_out_free_cleanup): New function.
(mi_on_normal_stop): If finishing an execution command started by
a CLI command, or any kind of breakpoint-like event triggered,
print the stop event to the output (CLI) stream.
* mi/mi-out.c (mi_ui_out_impl): Install NULL `dtor' handler.
2014-05-21 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-cli.exp (line_callee4_next_step): New global.
(top level): Test that output related to execution commands is
sent to the console with CLI commands, but not with MI commands.
Test that breakpoint events are always mirrored to the console.
Also expect the new source line to be output after a "next" in
async mode too. Make it a pass/fail test.
* gdb.mi/mi-solib.exp: Test that the CLI solib event note is
output.
* lib/mi-support.exp (mi_gdb_expect_cli_output): New procedure.
I noticed that "list" behaves differently in CLI vs MI. Particularly:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli...done.
(gdb) start
Temporary breakpoint 1 at 0x40054d: file ../../../src/gdb/testsuite/gdb.mi/basics.c, line 62.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62
62 callee1 (2, "A string argument.", 3.5);
(gdb) list
57 {
58 }
59
60 main ()
61 {
62 callee1 (2, "A string argument.", 3.5);
63 callee1 (2, "A string argument.", 3.5);
64
65 do_nothing (); /* Hello, World! */
66
(gdb)
Note the list started at line 57. IOW, the program stopped at line
62, and GDB centered the list on that.
compare with:
$ ./gdb -nx -q ./testsuite/gdb.mi/mi-cli -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/mi-cli..."
~"done.\n"
(gdb)
start
&"start\n"
...
~"\nTemporary breakpoint "
~"1, main () at ../../../src/gdb/testsuite/gdb.mi/basics.c:62\n"
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x000000000040054d",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/basics.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/basics.c",line="62"},thread-id="1",stopped-threads="all",core="0"
=breakpoint-deleted,id="1"
(gdb)
-interpreter-exec console list
~"62\t callee1 (2, \"A string argument.\", 3.5);\n"
~"63\t callee1 (2, \"A string argument.\", 3.5);\n"
~"64\t\n"
~"65\t do_nothing (); /* Hello, World! */\n"
~"66\t\n"
~"67\t callme (1);\n"
~"68\t callme (2);\n"
~"69\t\n"
~"70\t return 0;\n"
~"71\t}\n"
^done
(gdb)
Here the list starts at line 62, where the program was stopped.
This happens because print_stack_frame, called from both normal_stop
and mi_on_normal_stop, is the function responsible for setting the
current sal from the selected frame, overrides the PRINT_WHAT
argument, and only after that does it decide whether to center the
current sal line or not, based on the overridden value, and it will
always decide false.
(The print_stack_frame call in mi_on_normal_stop is a little different
from the call in normal_stop, in that it is an unconditional
SRC_AND_LOC call. A future patch will make those uniform.)
A previous version of this patch made MI uniform with CLI here, by
making print_stack_frame also center when MI is active. That changed
the output of a "list" command in mi-cli.exp, to expect line 57
instead of 62, as per the example above.
However, looking deeper, that list in question is the first "list"
after the program stops, and right after the stop, before the "list",
the test did "set listsize 1". Let's try the same thing with the CLI:
(gdb) start
62 callee1 (2, "A string argument.", 3.5);
(gdb) set listsize 1
(gdb) list
57 {
Huh, that's unexpected. Why the 57? It's because print_stack_frame,
called in reaction to the breakpoint stop, expecting the next "list"
to show 10 lines (the listsize at the time) around line 62, sets the
lines listed range to 57-67 (62 +/- 5). If the user changes the
listsize before "list", why would we still show that range? Looks
bogus to me.
So the fix for this whole issue should be delay trying to center the
listing to until actually listing, so that the correct listsize can be
taken into account. This makes MI and CLI uniform too, as it deletes
the center code from print_stack_frame.
A series of tests are added to list.exp to cover this. mi-cli.exp was
after all correct all along, but it now gains an additional test that
lists lines with listsize 10, to ensure the centering is consistent
with CLI's.
One related Python test changed related output -- it's a test that
prints the line number after stopping for a breakpoint, similar to the
new list.exp tests. Previously we'd print the stop line minus 5 (due
to the premature centering), now we print the stop line. I think
that's a good change.
Tested on x86_64 Fedora 20.
gdb/
2014-05-21 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (list_command): Handle the first "list" after the
current source line having changed.
* frame.h (set_current_sal_from_frame): Remove 'center' parameter.
* infrun.c (normal_stop): Adjust call to
set_current_sal_from_frame.
* source.c (clear_lines_listed_range): New function.
(set_current_source_symtab_and_line, identify_source_line): Clear
the lines listed range.
(line_info): Handle the first "info line" after the current source
line having changed.
* stack.c (print_stack_frame): Remove center handling.
(set_current_sal_from_frame): Remove 'center' parameter. Don't
center sal.line.
gdb/testsuite/
2014-05-21 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (build_pattern, test_list): New procedures.
Use them to test variations of "list" after reaching a breakpoint.
* gdb.mi/mi-cli.exp (line_main_callme_2): New global.
Test "list" with listsize 10 after reaching a breakpoint.
* gdb.python/python.exp (decode_line current location line
number): Adjust expected line number.
should_resume is set to 1 at the beginning and never changed.
gdb/ChangeLog:
2014-05-13 Simon Marchi <simon.marchi@ericsson.com>
* infrun.c (resume): Remove should_resume (unused). Move up
declaration of resume_ptid.
If a thread trips on a breakpoint that needs stepping over just after
finishing a step over, GDB currently fails an assertion. This is a
regression caused by the "Handle multiple step-overs." patch
(99619beac6) at
https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html.
(gdb) x /4i $pc
=> 0x400540 <main+4>: movl $0x0,0x2003da(%rip) # 0x600924 <i>
0x40054a <main+14>: movl $0x1,0x2003d0(%rip) # 0x600924 <i>
0x400554 <main+24>: movl $0x2,0x2003c6(%rip) # 0x600924 <i>
0x40055e <main+34>: movl $0x3,0x2003bc(%rip) # 0x600924 <i>
(gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses
break *0x40054a
Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition
break *0x400554
Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition
break *0x40055e
Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25.
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint
condition $bpnum condition
(gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition
break 27
Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27.
(gdb) continue
Continuing.
../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error)
The assertion fails, because the code is not expecting that the event
thread itself might need another step over. IOW, not expecting that
TP in:
tp = find_thread_needs_step_over (stepping_thread != NULL,
stepping_thread);
could be the event thread.
A small fix for this would be to clear the event thread's
trap_expected earlier, before asserting. But looking deeper, although
currently_stepping_or_nexting_callback's intention is finding the
thread that is doing a step/next, it also returns the thread that is
doing a step-over dance, with trap_expected set. If there ever was a
reason for that (it was I who added
currently_stepping_or_nexting_callback , but I can't recall why I put
trap_expected there in the first place), the only remaining reason
nowadays is to aid in implementing switch_back_to_stepped_thread's
assertion that is now triggering, by piggybacking on the walk over all
threads, thus avoiding a separate walk. This is quite obscure, and I
think we can do even better, by merging the walks that look for the
stepping thread, and the walk that looks for some thread that might
need a step over.
Tested on x86_64 Fedora 17, native and gdbserver, and also native on
top of my "software single-step on x86_64" series.
gdb/
2014-04-22 Pedro Alves <palves@redhat.com>
* infrun.c (schedlock_applies): New function, factored out from
find_thread_needs_step_over.
(find_thread_needs_step_over): Use it.
(switch_back_to_stepped_thread): Always clear trap_expected if the
step over is finished. Return early if scheduler locking applies.
Look for the stepping thread and a potential step-over thread with
a single loop.
(currently_stepping_or_nexting_callback): Delete.
2014-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/consecutive-step-over.c: New file.
* gdb.base/consecutive-step-over.exp: New file.
This test fails with current mainline.
If the program stopped for a breakpoint in thread 1, and then the user
switches to thread 2, and resumes the program, GDB first switches back
to thread 1 to step it over the breakpoint, in order to make progress.
However, that logic only considers the last reported event, assuming
only one thread needs that stepping over dance.
That's actually not true when we play with scheduler-locking. The
patch adds an example to the testsuite of multiple threads needing a
step-over before the stepping thread can be resumed. With current
mainline, the program re-traps the same breakpoint it had already
trapped before.
E.g.:
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint
info threads
Id Target Id Frame
3 Thread 0x7ffff77c9700 (LWP 4310) "multiple-step-o" 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
2 Thread 0x7ffff7fca700 (LWP 4309) "multiple-step-o" 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
* 1 Thread 0x7ffff7fcb740 (LWP 4305) "multiple-step-o" main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: info threads shows all threads
set scheduler-locking on
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking on
break 44
Breakpoint 3 at 0x4007d3: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 44.
(gdb) break 61
Breakpoint 4 at 0x40082d: file ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 61.
(gdb) thread 3
[Switching to thread 3 (Thread 0x7ffff77c9700 (LWP 4310))]
#0 0x00000000004007ca in child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:43
43 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 3
continue
Continuing.
Breakpoint 3, child_function_3 (arg=0x1) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:44
44 callme (); /* set breakpoint thread 3 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 3
p *myp = 0
$1 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 3
thread 2
[Switching to thread 2 (Thread 0x7ffff7fca700 (LWP 4309))]
#0 0x0000000000400827 in child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:60
60 (*myp) ++;
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 2
continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:61
61 callme (); /* set breakpoint thread 2 here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: continue to breakpoint: run to breakpoint in thread 2
p *myp = 0
$2 = 0
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: unbreak loop in thread 2
thread 1
[Switching to thread 1 (Thread 0x7ffff7fcb740 (LWP 4305))]
#0 main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: thread 1
set scheduler-locking off
(gdb) PASS: gdb.threads/multiple-step-overs.exp: step: set scheduler-locking off
At this point all thread are stopped for a breakpoint that needs stepping over.
(gdb) step
Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.threads/multiple-step-overs.c:99
99 wait_threads (); /* set wait-threads breakpoint here */
(gdb) FAIL: gdb.threads/multiple-step-overs.exp: step
But that "step" retriggers the same breakpoint instead of making
progress.
The patch teaches GDB to step over all breakpoints of all threads
before resuming the stepping thread.
Tested on x86_64 Fedora 17, against pristine mainline, and also my
branch that implements software single-stepping on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (prepare_to_proceed): Delete.
(thread_still_needs_step_over): New function.
(find_thread_needs_step_over): New function.
(proceed): If the current thread needs a step-over, set its
steping_over_breakpoint flag. Adjust to use
find_thread_needs_step_over instead of prepare_to_proceed.
(process_event_stop_test): For BPSTAT_WHAT_STOP_NOISY and
BPSTAT_WHAT_STOP_SILENT, assume the thread stopped for a
breakpoint.
(switch_back_to_stepped_thread): Step over breakpoints of all
threads not the stepping thread, before switching back to the
stepping thread.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multiple-step-overs.c: New file.
* gdb.threads/multiple-step-overs.exp: New file.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Adjust expected infrun debug output.
Even with deferred_step_ptid out of the way, GDB can still lose
watchpoints.
If a watchpoint triggers and the PC points to an address where a
thread-specific breakpoint for another thread is set, the thread-hop
code triggers, and we lose the watchpoint:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
{
int thread_hop_needed = 0;
struct address_space *aspace =
get_regcache_aspace (get_thread_regcache (ecs->ptid));
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
^^^^^^^^^^^^^^^^^^^^^
}
And on software single-step targets, even without a thread-specific
breakpoint in the way, here in the thread-hop code:
else if (singlestep_breakpoints_inserted_p)
{
...
if (!ptid_equal (singlestep_ptid, ecs->ptid)
&& in_thread_list (singlestep_ptid))
{
/* If the PC of the thread we were trying to single-step
has changed, discard this event (which we were going
to ignore anyway), and pretend we saw that thread
trap. This prevents us continuously moving the
single-step breakpoint forward, one instruction at a
time. If the PC has changed, then the thread we were
trying to single-step has trapped or been signalled,
but the event has not been reported to GDB yet.
There might be some cases where this loses signal
information, if a signal has arrived at exactly the
same time that the PC changed, but this is the best
we can do with the information available. Perhaps we
should arrange to report all events for all threads
when they stop, or to re-poll the remote looking for
this particular thread (i.e. temporarily enable
schedlock). */
CORE_ADDR new_singlestep_pc
= regcache_read_pc (get_thread_regcache (singlestep_ptid));
if (new_singlestep_pc != singlestep_pc)
{
enum gdb_signal stop_signal;
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: unexpected thread,"
" but expected thread advanced also\n");
/* The current context still belongs to
singlestep_ptid. Don't swap here, since that's
the context we want to use. Just fudge our
state and continue. */
stop_signal = ecs->event_thread->suspend.stop_signal;
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
ecs->ptid = singlestep_ptid;
ecs->event_thread = find_thread_ptid (ecs->ptid);
ecs->event_thread->suspend.stop_signal = stop_signal;
stop_pc = new_singlestep_pc;
}
else
{
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: unexpected thread\n");
thread_hop_needed = 1;
stepping_past_singlestep_breakpoint = 1;
saved_singlestep_ptid = singlestep_ptid;
}
}
}
we either end up with thread_hop_needed, ignoring the watchpoint
SIGTRAP, or switch to the stepping thread, again ignoring that the
SIGTRAP could be for some other event.
The new test added by this patch exercises both paths.
So the fix is similar to the deferred_step_ptid fix -- defer the
thread hop to _after_ the SIGTRAP had a change of passing through the
regular bpstat handling. If the wrong thread hits a breakpoint, we'll
just end up with BPSTAT_WHAT_SINGLE, and if nothing causes a stop,
keep_going starts a step-over.
Most of the stepping_past_singlestep_breakpoint mechanism is really
not necessary -- setting the thread to step over a breakpoint with
thread->trap_expected is sufficient to keep all other threads locked.
It's best to still keep the flag in some form though, because when we
get to keep_going, the software single-step breakpoint we need to step
over is already gone -- an optimization done by a follow up patch will
check whether a step-over is still be necessary by looking to see
whether the breakpoint is still there, and would find the thread no
longer needs a step-over, while we still want it.
Special care is still needed to handle the case of PC of the thread we
were trying to single-step having changed, like in the old code. We
can't just keep_going and re-step it, as in that case we can over-step
the thread (if it was already done with the step, but hasn't reported
it yet, we'd ask it to step even further). That's now handled in
switch_back_to_stepped_thread. As bonus, we're now using a technique
that doesn't lose signals, unlike the old code -- we now insert a
breakpoint at PC, and resume, which either reports the breakpoint
immediately, or any pending signal.
Tested on x86_64 Fedora 17, against pristine mainline, and against a
branch that implements software single-step on x86.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* breakpoint.c (single_step_breakpoint_inserted_here_p): Make
extern.
* breakpoint.h (single_step_breakpoint_inserted_here_p): Declare.
* infrun.c (saved_singlestep_ptid)
(stepping_past_singlestep_breakpoint): Delete.
(resume): Remove stepping_past_singlestep_breakpoint handling.
(proceed): Store the prev_pc of the stepping thread too.
(init_wait_for_inferior): Adjust. Clear singlestep_ptid and
singlestep_pc.
(enum infwait_states): Delete infwait_thread_hop_state.
(struct execution_control_state) <hit_singlestep_breakpoint>: New
field.
(handle_inferior_event): Adjust.
(handle_signal_stop): Delete stepping_past_singlestep_breakpoint
handling and the thread-hop code. Before removing single-step
breakpoints, check whether the thread hit a single-step breakpoint
of another thread. If it did, the trap is not a random signal.
(switch_back_to_stepped_thread): If the event thread hit a
single-step breakpoint, unblock it before switching to the
stepping thread. Handle the case of the stepped thread having
advanced already.
(keep_going): Handle the case of the current thread moving past a
single-step breakpoint.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-trips-on-watchpoint.c: New file.
* gdb.threads/step-over-trips-on-watchpoint.exp: New file.
Say the program is stopped at a breakpoint, and the user sets a
watchpoint. When the program is next resumed, GDB will first step
over the breakpoint, as explained in the manual:
@value {GDBN} normally ignores breakpoints when it resumes
execution, until at least one instruction has been executed. If it
it did not do this, you would be unable to proceed past a breakpoint
without first disabling the breakpoint. This rule applies whether
or not the breakpoint already existed when your program stopped.
However, GDB currently also removes watchpoints, catchpoints, etc.,
and that means that the first instruction off the breakpoint does not
trigger the watchpoint, catchpoint, etc.
testsuite/gdb.base/watchpoint.exp has a kfail for this.
The PR proposes installing watchpoints only when stepping over a
breakpoint, but that misses catchpoints, etc.
A better fix would instead work from the opposite direction -- remove
only real breakpoints, leaving all other kinds of breakpoints
inserted.
But, going further, it's really a waste to constantly remove/insert
all breakpoints when stepping over a single breakpoint (generating a
pair of RSP z/Z packets for each breakpoint), so the fix goes a step
further and makes GDB remove _only_ the breakpoint being stepped over,
leaving all others installed. This then has the added benefit of
reducing breakpoint-related RSP traffic substancialy when there are
many breakpoints set.
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* breakpoint.c (should_be_inserted): Don't insert breakpoints that
are being stepped over.
(breakpoint_address_match): Make extern.
* breakpoint.h (breakpoint_address_match): New declaration.
* inferior.h (stepping_past_instruction_at): New declaration.
* infrun.c (struct step_over_info): New type.
(step_over_info): New global.
(set_step_over_info, clear_step_over_info)
(stepping_past_instruction_at): New functions.
(handle_inferior_event): Clear the step-over info when
trap_expected is cleared.
(resume): Remove now stale comment.
(clear_proceed_status): Clear step-over info.
(proceed): Adjust step-over handling to set or clear the step-over
info instead of removing all breakpoints.
(handle_signal_stop): When setting up a thread-hop, don't remove
breakpoints here.
(stop_stepping): Clear step-over info.
(keep_going): Adjust step-over handling to set or clear step-over
info and then always inserting breakpoints, instead of removing
all breakpoints when stepping over one.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
PR breakpoints/7143
* gdb.base/watchpoint.exp: Mention bugzilla bug number instead of
old gnats gdb/38. Remove kfail. Adjust to use gdb_test instead
of gdb_test_multiple.
* gdb.cp/annota2.exp: Remove kfail for gdb/38.
* gdb.cp/annota3.exp: Remove kfail for gdb/38.
Consider the case of the user doing "step" in thread 2, while thread 1
had previously stopped for a breakpoint. In order to make progress,
GDB makes thread 1 step over its breakpoint first (with all other
threads stopped), and once that is over, thread 2 then starts stepping
(with thread 1 and all others running free, by default). If GDB
didn't do that, thread 1 would just trip on the same breakpoint
immediately again. This is what the prepare_to_proceed /
deferred_step_ptid code is all about.
However, deferred_step_ptid code resumes the target with:
resume (1, GDB_SIGNAL_0);
prepare_to_wait (ecs);
return;
Recall we were just stepping over a breakpoint when we get here. That
means that _nothing_ had installed breakpoints yet! If there's
another breakpoint just after the breakpoint that was just stepped,
we'll miss it. The fix for that would be to use keep_going instead.
However, there are more problems. What if the instruction that was
just single-stepped triggers a watchpoint? Currently, GDB just
happily resumes the thread, losing that too...
Missed watchpoints will need yet further fixes, but we should keep
those in mind.
So the fix must be to let the trap fall through the regular bpstat
handling, and only if no breakpoint, watchpoint, etc. claims the trap,
shall we switch back to the stepped thread.
Now, nowadays, we have code at the tail end of trap handling that does
exactly that -- switch back to the stepped thread
(switch_back_to_the_stepped_thread).
So the deferred_step_ptid code is just standing in the way, and can
simply be eliminated, fixing bugs in the process. Sweet.
The comment about spurious "Switching to ..." made me pause, but is
actually stale nowadays. That isn't needed anymore.
previous_inferior_ptid used to be re-set at each (internal) event, but
now it's only touched in proceed and normal stop.
The two tests added by this patch fail without the fix.
Tested on x86_64 Fedora 17 (also against my software single-stepping
on x86 branch).
gdb/
2014-03-20 Pedro Alves <palves@redhat.com>
* infrun.c (previous_inferior_ptid): Adjust comment.
(deferred_step_ptid): Delete.
(infrun_thread_ptid_changed, prepare_to_proceed)
(init_wait_for_inferior): Adjust.
(handle_signal_stop): Delete deferred_step_ptid handling.
gdb/testsuite/
2014-03-20 Pedro Alves <palves@redhat.com>
* gdb.threads/step-over-lands-on-breakpoint.c: New file.
* gdb.threads/step-over-lands-on-breakpoint.exp: New file.
Part of PR gdb/13860 is about the mi-solib.exp test's output being
different in sync vs async modes.
sync:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17724"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
async:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async on" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
start
&"start\n"
~"Temporary breakpoint 1 at 0x400608: file ../../../src/gdb/testsuite/gdb.mi/solib-main.c, line 21.\n"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0000000000400608",func="main",file="../../../src/gdb/testsuite/gdb.mi/solib-main.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.mi/solib-main.c",line="21",times="0",original-location="main"}
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17729"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
(gdb)
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
For now, let's focus only on the *stopped event. We see that the
async output is missing frame info. And this causes a test failure in
async mode, as "mi_expect_stop solib-event" wants to see the frame
info.
However, if we compare the event output when a real MI execution
command is used, compared to a CLI command (e.g., run vs -exec-run,
next vs -exec-next, etc.), we see:
>./gdb -nx -q ./testsuite/gdb.mi/solib-main -ex "set stop-on-solib-events 1" -ex "set target-async off" -i=mi
=thread-group-added,id="i1"
~"Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main..."
~"done.\n"
(gdb)
r
&"r\n"
~"Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.mi/solib-main \n"
=thread-group-started,id="i1",pid="17751"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
~"Stopped due to shared library event (no libraries added or removed)\n"
*stopped,reason="solib-event",frame={addr="0x000000379180f990",func="_dl_debug_state",args=[],from="/lib64/ld-linux-x86-64.so.2"},thread-id="1",stopped-threads="all",core="3"
(gdb)
-exec-run
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
=library-unloaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",thread-group="i1"
=thread-group-started,id="i1",pid="17754"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
*stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
=thread-selected,id="1"
(gdb)
As seen above, with MI commands, the *stopped event _doesn't_ have
frame info. This is because normal_stop, as commanded by the result
of bpstat_print, skips printing frame info in this case (it's an
"event", not a "breakpoint"), and when the interpreter is MI,
mi_on_normal_stop skips calling print_stack_frame, as the normal_stop
call was already done with the MI uiout. This explains why the async
output is different even with a CLI command. Its because in async
mode, the mi_on_normal_stop path is always taken; it is always reached
with the MI uiout, because the stop is handled from the event loop,
instead of from within `proceed -> wait_for_inferior -> normal_stop'
with the interpreter overridden, as in sync mode.
This patch fixes the issue by making all cases output the same
*stopped event, by factoring out the print code from normal_stop, and
using it from mi_on_normal_stop as well. I chose the *stopped output
without a frame, mainly because that is what you already get if you
use MI execution commands, the commands frontends are supposed to use
(except when implementing a console). This patch makes it simpler to
tweak the MI output differently if desired, as we only have to change
the centralized print_stop_event (taking into account whether the
uiout is MI-like), and all different modes will change accordingly.
Tested on x86_64 Fedora 17, no regressions. The mi-solib.exp test no
longer fails in async mode with this patch, so the patch removes the
kfail.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* inferior.h (print_stop_event): Declare.
* infrun.c (print_stop_event): New, factored out from ...
(normal_stop): ... this.
* mi/mi-interp.c (mi_on_normal_stop): Use print_stop_event instead
of bpstat_print/print_stack_frame.
2014-03-18 Pedro Alves <palves@redhat.com>
PR gdb/13860
* gdb.mi/mi-solib.exp: Remove gdb/13860 kfail.
* lib/mi-support.exp (mi_expect_stop): Add special handling for
solib-event.
This changes the probes to be independent of the program space.
After this, when a probe's address is needed, it is determined by
applying offsets at the point of use.
This introduces a bound_probe object, similar to bound minimal
symbols. Objects of this type are used when it's necessary to pass a
probe and its corresponding objfile.
This removes the backlink from probe to objfile, which was primarily
used to fetch the architecture to use.
This adds a get_probe_address function which calls a probe method to
compute the probe's relocated address. Similarly, it adds an objfile
parameter to the semaphore methods so they can do the relocation
properly as well.
2014-03-03 Tom Tromey <tromey@redhat.com>
* break-catch-throw.c (fetch_probe_arguments): Use bound probes.
* breakpoint.c (create_longjmp_master_breakpoint): Use
get_probe_address.
(add_location_to_breakpoint, bkpt_probe_insert_location)
(bkpt_probe_remove_location): Update.
* breakpoint.h (struct bp_location) <probe>: Now a bound_probe.
* elfread.c (elf_symfile_relocate_probe): Remove.
(elf_probe_fns): Update.
(insert_exception_resume_breakpoint): Change type of "probe"
parameter to bound_probe.
(check_exception_resume): Update.
* objfiles.c (objfile_relocate1): Don't relocate probes.
* probe.c (bound_probe_s): New typedef.
(parse_probes): Use get_probe_address. Set sal's objfile.
(find_probe_by_pc): Return a bound_probe.
(collect_probes): Return a VEC(bound_probe_s).
(compare_probes): Update.
(gen_ui_out_table_header_info): Change type of "probes"
parameter. Update.
(info_probes_for_ops): Update.
(get_probe_address): New function.
(probe_safe_evaluate_at_pc): Update.
* probe.h (struct probe_ops) <get_probe_address>: New field.
<set_semaphore, clear_semaphore>: Add objfile parameter.
(struct probe) <objfile>: Remove field.
<arch>: New field.
<address>: Update comment.
(struct bound_probe): New.
(find_probe_by_pc): Return a bound_probe.
(get_probe_address): Declare.
* solib-svr4.c (struct probe_and_action) <address>: New field.
(hash_probe_and_action, equal_probe_and_action): Update.
(register_solib_event_probe): Add address parameter.
(solib_event_probe_at): Update.
(svr4_create_probe_breakpoints): Add objfile parameter. Use
get_probe_address.
* stap-probe.c (struct stap_probe) <sem_addr>: Update comment.
(stap_get_probe_address): New function.
(stap_can_evaluate_probe_arguments, compute_probe_arg)
(compile_probe_arg): Update.
(stap_set_semaphore, stap_clear_semaphore): Compute semaphore's
address.
(handle_stap_probe): Don't relocate the probe.
(stap_relocate): Remove.
(stap_gen_info_probes_table_values): Update.
(stap_probe_ops): Remove stap_relocate.
* symfile-debug.c (debug_sym_relocate_probe): Remove.
(debug_sym_probe_fns): Update.
* symfile.h (struct sym_probe_fns) <sym_relocate_probe>: Remove.
* symtab.c (init_sal): Use memset.
* symtab.h (struct symtab_and_line) <objfile>: New field.
* tracepoint.c (start_tracing, stop_tracing): Update.
Say:
<stopped at a breakpoint in thread 2>
(gdb) thread 3
(gdb) step
The above triggers the prepare_to_proceed/deferred_step_ptid process,
which switches back to thread 2, to step over its breakpoint before
getting back to thread 3 and "step" it.
If while stepping over the breakpoint in thread 2, a signal arrives,
and it is set to pass/nostop, we'll set a step-resume breakpoint at
the supposed signal-handler resume address, and call keep_going. The
problem is that we were supposedly stepping thread 3, and that
keep_going delivers a signal to thread 2, and due to scheduler-locking
off, resumes everything else, _including_ thread 3, the thread we want
stepping. This means that we lose control of thread 3 until the next
event, when we stop everything. The end result for the user, is that
GDB lost control of the "step".
Here's the current infrun debug output of the above, with the testcase
in the patch below:
infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663))
infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662))
infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659))
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)]
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGUSR1
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: random signal 30
Program received signal SIGUSR1, User defined signal 1.
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x40098f
infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ this is a wildcard resume.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: BPSTAT_WHAT_STEP_RESUME
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40088b
infrun: switching back to stepped thread
infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40093a
infrun: keep going
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40091e
infrun: stepped to a different line
infrun: stop_stepping
[Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
69 (*myp) ++; /* set breakpoint child_two here */
^^^ we stopped at the wrong line. We still stepped a bit because the
test is running in a loop, and when we got back to stepping thread 3,
it happened to be in the stepping range. (The loop increments a
counter, and the test makes sure it increments exactly once. Without
the fix, the counter increments a bunch, since the user-stepped thread
runs free without GDB noticing.)
The fix is to switch to the stepping thread before continuing for the
step-resume breakpoint.
gdb/
2014-02-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop) <signal arrives while stepping
over a breakpoint>: Switch back to the stepping thread.
gdb/testsuite/
2014-02-07 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: New file.
* gdb.threads/step-after-sr-lock.exp: New file.
This patch handles another aspect of the ELFv2 ABI, which unfortunately
requires common code changes.
In ELFv2, functions may provide both a global and a local entry point.
The global entry point (where the function symbol points to) is intended
to be used for function-pointer or cross-module (PLT) calls, and requires
r12 to be set up to the entry point address itself. The local entry
point (which is found at a fixed offset after the global entry point,
as defined by bits in the symbol table entries' st_other field), instead
expects r2 to be set up to the current TOC.
Now, when setting a breakpoint on a function by name, you really want
that breakpoint to trigger either way, no matter whether the function
is called via its local or global entry point. Since the global entry
point will always fall through into the local entry point, the way to
achieve that is to simply set the breakpoint at the local entry point.
One way to do that would be to have prologue parsing skip the code
sequence that makes up the global entry point. Unfortunately, this
does not work reliably, since -for optimized code- GDB these days
will not actuall invoke the prologue parsing code but instead just
set the breakpoint at the symbol address and rely on DWARF being
correct at any point throughout the function ...
Unfortunately, I don't really see any way to express the notion of
local entry points with the current set of gdbarch callbacks.
Thus this patch adds a new callback, skip_entrypoint, that is
somewhat analogous to skip_prologue, but is called every time
GDB needs to determine a function start address, even in those
cases where GDB decides to not call skip_prologue.
As a side effect, the skip_entrypoint implementation on ppc64
does not need to perform any instruction parsing; it can simply
rely on the local entry point flags in the symbol table entry.
With this implemented, two test cases would still fail to set
the breakpoint correctly, but that's because they use the construct:
gdb_test "break *hello"
Now, using "*hello" explicitly instructs GDB to set the breakpoint
at the numerical value of "hello" treated as function pointer, so
it will by definition only hit the global entry point.
I think this behaviour is unavoidable, but acceptable -- most people
do not use this construct, and if they do, they get what they
asked for ...
In one of those two test cases, use of this construct is really
not appropriate. I think this was added way back when as a means
to work around prologue skipping problems on some platforms. These
days that shouldn't really be necessary any more ...
For the other (step-bt), we really want to make sure backtracing
works on the very first instruction of the routine. To enable that
test also on powerpc64le-linux, we can modify the code to call the
test function via function pointer (which makes it use the global
entry point in the ELFv2 ABI).
gdb/ChangeLog:
* gdbarch.sh (skip_entrypoint): New callback.
* gdbarch.c, gdbarch.h: Regenerate.
* symtab.c (skip_prologue_sal): Call gdbarch_skip_entrypoint.
* infrun.c (fill_in_stop_func): Likewise.
* ppc-linux-tdep.c: Include "elf/ppc64.h".
(ppc_elfv2_elf_make_msymbol_special): New function.
(ppc_elfv2_skip_entrypoint): Likewise.
(ppc_linux_init_abi): Install them for ELFv2.
gdb/testsuite/ChangeLog:
* gdb.base/sigbpt.exp: Do not use "*" when setting breakpoint
on a function.
* gdb.base/step-bt.c: Call hello via function pointer to make
sure its first instruction is executed on powerpc64le-linux.
RECORD_IS_USED and record_full_open look at current_target.to_stratum
to determine whether a record target is in use. This is wrong because
arch_stratum is greater than record_stratum, so if an arch_stratum
target is pushed, RECORD_IS_USED and record_full_open will miss it.
To fix this, we can use the existing find_record_target instead, which
looks up for a record stratum target across the target stack. Since
that means exporting find_record_target in record.h, RECORD_IS_USED
ends up redundant, so the patch eliminates it.
That exercise then reveals other issues:
- adjust_pc_after_break is gating record_full_... calls based on
RECORD_IS_USED. But, record_full_ calls shouldn't be made when
recording with the record-btrace target. So this adds a new
record_full_is_used predicate to be used in that spot.
- record_full_open says "Process record target already running", even
if the recording target is record-btrace ("process record" is the
original complete name of the record-full target). record_btrace_open
only says "The process is already being recorded." and does not
suggest "record stop", like record-full does. The patch factors out
and merges that error to a new record_preopen function that all record
targets call in their open routine.
Tested on x86_64 Fedora 17.
gdb/
2014-01-14 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@redhat.com>
* infrun.c (use_displaced_stepping): Use find_record_target
instead of RECORD_IS_USED.
(adjust_pc_after_break): Use record_full_is_used instead of
RECORD_IS_USED.
* record-btrace.c (record_btrace_open): Call record_preopen
instead of checking RECORD_IS_USED.
* record-full.c (record_full_shortname)
(record_full_core_shortname): New globals.
(record_full_is_used): New function.
(find_full_open): Call record_preopen instead of checking
RECORD_IS_USED.
(init_record_full_ops): Set the target's shortname to
record_full_shortname.
(init_record_full_core_ops): Set the target's shortname to
record_full_core_shortname.
* record-full.h (record_full_is_used): Declare.
* record.c (find_record_target): Make extern.
(record_preopen): New function.
* record.h (RECORD_IS_USED): Delete macro.
(find_record_target, record_preopen): Declare functions.
This removes gdb_string.h. This patch is purely mechanical. I
created it by running the two commands:
git rm common/gdb_string.h
perl -pi -e's/"gdb_string.h"/<string.h>/;' *.[chyl] */*.[chyl]
2013-11-18 Tom Tromey <tromey@redhat.com>
* common/gdb_string.h: Remove.
* aarch64-tdep.c: Use string.h, not gdb_string.h.
* ada-exp.y: Use string.h, not gdb_string.h.
* ada-lang.c: Use string.h, not gdb_string.h.
* ada-lex.l: Use string.h, not gdb_string.h.
* ada-typeprint.c: Use string.h, not gdb_string.h.
* ada-valprint.c: Use string.h, not gdb_string.h.
* aix-thread.c: Use string.h, not gdb_string.h.
* alpha-linux-tdep.c: Use string.h, not gdb_string.h.
* alpha-mdebug-tdep.c: Use string.h, not gdb_string.h.
* alpha-nat.c: Use string.h, not gdb_string.h.
* alpha-osf1-tdep.c: Use string.h, not gdb_string.h.
* alpha-tdep.c: Use string.h, not gdb_string.h.
* alphanbsd-tdep.c: Use string.h, not gdb_string.h.
* amd64-dicos-tdep.c: Use string.h, not gdb_string.h.
* amd64-linux-nat.c: Use string.h, not gdb_string.h.
* amd64-linux-tdep.c: Use string.h, not gdb_string.h.
* amd64-nat.c: Use string.h, not gdb_string.h.
* amd64-sol2-tdep.c: Use string.h, not gdb_string.h.
* amd64fbsd-tdep.c: Use string.h, not gdb_string.h.
* amd64obsd-tdep.c: Use string.h, not gdb_string.h.
* arch-utils.c: Use string.h, not gdb_string.h.
* arm-linux-nat.c: Use string.h, not gdb_string.h.
* arm-linux-tdep.c: Use string.h, not gdb_string.h.
* arm-tdep.c: Use string.h, not gdb_string.h.
* arm-wince-tdep.c: Use string.h, not gdb_string.h.
* armbsd-tdep.c: Use string.h, not gdb_string.h.
* armnbsd-nat.c: Use string.h, not gdb_string.h.
* armnbsd-tdep.c: Use string.h, not gdb_string.h.
* armobsd-tdep.c: Use string.h, not gdb_string.h.
* avr-tdep.c: Use string.h, not gdb_string.h.
* ax-gdb.c: Use string.h, not gdb_string.h.
* ax-general.c: Use string.h, not gdb_string.h.
* bcache.c: Use string.h, not gdb_string.h.
* bfin-tdep.c: Use string.h, not gdb_string.h.
* breakpoint.c: Use string.h, not gdb_string.h.
* build-id.c: Use string.h, not gdb_string.h.
* buildsym.c: Use string.h, not gdb_string.h.
* c-exp.y: Use string.h, not gdb_string.h.
* c-lang.c: Use string.h, not gdb_string.h.
* c-typeprint.c: Use string.h, not gdb_string.h.
* c-valprint.c: Use string.h, not gdb_string.h.
* charset.c: Use string.h, not gdb_string.h.
* cli-out.c: Use string.h, not gdb_string.h.
* cli/cli-cmds.c: Use string.h, not gdb_string.h.
* cli/cli-decode.c: Use string.h, not gdb_string.h.
* cli/cli-dump.c: Use string.h, not gdb_string.h.
* cli/cli-interp.c: Use string.h, not gdb_string.h.
* cli/cli-logging.c: Use string.h, not gdb_string.h.
* cli/cli-script.c: Use string.h, not gdb_string.h.
* cli/cli-setshow.c: Use string.h, not gdb_string.h.
* cli/cli-utils.c: Use string.h, not gdb_string.h.
* coffread.c: Use string.h, not gdb_string.h.
* common/common-utils.c: Use string.h, not gdb_string.h.
* common/filestuff.c: Use string.h, not gdb_string.h.
* common/linux-procfs.c: Use string.h, not gdb_string.h.
* common/linux-ptrace.c: Use string.h, not gdb_string.h.
* common/signals.c: Use string.h, not gdb_string.h.
* common/vec.h: Use string.h, not gdb_string.h.
* core-regset.c: Use string.h, not gdb_string.h.
* corefile.c: Use string.h, not gdb_string.h.
* corelow.c: Use string.h, not gdb_string.h.
* cp-abi.c: Use string.h, not gdb_string.h.
* cp-support.c: Use string.h, not gdb_string.h.
* cp-valprint.c: Use string.h, not gdb_string.h.
* cris-tdep.c: Use string.h, not gdb_string.h.
* d-lang.c: Use string.h, not gdb_string.h.
* dbxread.c: Use string.h, not gdb_string.h.
* dcache.c: Use string.h, not gdb_string.h.
* demangle.c: Use string.h, not gdb_string.h.
* dicos-tdep.c: Use string.h, not gdb_string.h.
* disasm.c: Use string.h, not gdb_string.h.
* doublest.c: Use string.h, not gdb_string.h.
* dsrec.c: Use string.h, not gdb_string.h.
* dummy-frame.c: Use string.h, not gdb_string.h.
* dwarf2-frame.c: Use string.h, not gdb_string.h.
* dwarf2loc.c: Use string.h, not gdb_string.h.
* dwarf2read.c: Use string.h, not gdb_string.h.
* elfread.c: Use string.h, not gdb_string.h.
* environ.c: Use string.h, not gdb_string.h.
* eval.c: Use string.h, not gdb_string.h.
* event-loop.c: Use string.h, not gdb_string.h.
* exceptions.c: Use string.h, not gdb_string.h.
* exec.c: Use string.h, not gdb_string.h.
* expprint.c: Use string.h, not gdb_string.h.
* f-exp.y: Use string.h, not gdb_string.h.
* f-lang.c: Use string.h, not gdb_string.h.
* f-typeprint.c: Use string.h, not gdb_string.h.
* f-valprint.c: Use string.h, not gdb_string.h.
* fbsd-nat.c: Use string.h, not gdb_string.h.
* findcmd.c: Use string.h, not gdb_string.h.
* findvar.c: Use string.h, not gdb_string.h.
* fork-child.c: Use string.h, not gdb_string.h.
* frame.c: Use string.h, not gdb_string.h.
* frv-linux-tdep.c: Use string.h, not gdb_string.h.
* frv-tdep.c: Use string.h, not gdb_string.h.
* gdb.c: Use string.h, not gdb_string.h.
* gdb_bfd.c: Use string.h, not gdb_string.h.
* gdbarch.c: Use string.h, not gdb_string.h.
* gdbtypes.c: Use string.h, not gdb_string.h.
* gnu-nat.c: Use string.h, not gdb_string.h.
* gnu-v2-abi.c: Use string.h, not gdb_string.h.
* gnu-v3-abi.c: Use string.h, not gdb_string.h.
* go-exp.y: Use string.h, not gdb_string.h.
* go-lang.c: Use string.h, not gdb_string.h.
* go32-nat.c: Use string.h, not gdb_string.h.
* hppa-hpux-tdep.c: Use string.h, not gdb_string.h.
* hppa-linux-nat.c: Use string.h, not gdb_string.h.
* hppanbsd-tdep.c: Use string.h, not gdb_string.h.
* hppaobsd-tdep.c: Use string.h, not gdb_string.h.
* i386-cygwin-tdep.c: Use string.h, not gdb_string.h.
* i386-dicos-tdep.c: Use string.h, not gdb_string.h.
* i386-linux-nat.c: Use string.h, not gdb_string.h.
* i386-linux-tdep.c: Use string.h, not gdb_string.h.
* i386-nto-tdep.c: Use string.h, not gdb_string.h.
* i386-sol2-tdep.c: Use string.h, not gdb_string.h.
* i386-tdep.c: Use string.h, not gdb_string.h.
* i386bsd-tdep.c: Use string.h, not gdb_string.h.
* i386gnu-nat.c: Use string.h, not gdb_string.h.
* i386nbsd-tdep.c: Use string.h, not gdb_string.h.
* i386obsd-tdep.c: Use string.h, not gdb_string.h.
* i387-tdep.c: Use string.h, not gdb_string.h.
* ia64-libunwind-tdep.c: Use string.h, not gdb_string.h.
* ia64-linux-nat.c: Use string.h, not gdb_string.h.
* inf-child.c: Use string.h, not gdb_string.h.
* inf-ptrace.c: Use string.h, not gdb_string.h.
* inf-ttrace.c: Use string.h, not gdb_string.h.
* infcall.c: Use string.h, not gdb_string.h.
* infcmd.c: Use string.h, not gdb_string.h.
* inflow.c: Use string.h, not gdb_string.h.
* infrun.c: Use string.h, not gdb_string.h.
* interps.c: Use string.h, not gdb_string.h.
* iq2000-tdep.c: Use string.h, not gdb_string.h.
* irix5-nat.c: Use string.h, not gdb_string.h.
* jv-exp.y: Use string.h, not gdb_string.h.
* jv-lang.c: Use string.h, not gdb_string.h.
* jv-typeprint.c: Use string.h, not gdb_string.h.
* jv-valprint.c: Use string.h, not gdb_string.h.
* language.c: Use string.h, not gdb_string.h.
* linux-fork.c: Use string.h, not gdb_string.h.
* linux-nat.c: Use string.h, not gdb_string.h.
* lm32-tdep.c: Use string.h, not gdb_string.h.
* m2-exp.y: Use string.h, not gdb_string.h.
* m2-typeprint.c: Use string.h, not gdb_string.h.
* m32c-tdep.c: Use string.h, not gdb_string.h.
* m32r-linux-nat.c: Use string.h, not gdb_string.h.
* m32r-linux-tdep.c: Use string.h, not gdb_string.h.
* m32r-rom.c: Use string.h, not gdb_string.h.
* m32r-tdep.c: Use string.h, not gdb_string.h.
* m68hc11-tdep.c: Use string.h, not gdb_string.h.
* m68k-tdep.c: Use string.h, not gdb_string.h.
* m68kbsd-tdep.c: Use string.h, not gdb_string.h.
* m68klinux-nat.c: Use string.h, not gdb_string.h.
* m68klinux-tdep.c: Use string.h, not gdb_string.h.
* m88k-tdep.c: Use string.h, not gdb_string.h.
* macrocmd.c: Use string.h, not gdb_string.h.
* main.c: Use string.h, not gdb_string.h.
* mdebugread.c: Use string.h, not gdb_string.h.
* mem-break.c: Use string.h, not gdb_string.h.
* memattr.c: Use string.h, not gdb_string.h.
* memory-map.c: Use string.h, not gdb_string.h.
* mep-tdep.c: Use string.h, not gdb_string.h.
* mi/mi-cmd-break.c: Use string.h, not gdb_string.h.
* mi/mi-cmd-disas.c: Use string.h, not gdb_string.h.
* mi/mi-cmd-env.c: Use string.h, not gdb_string.h.
* mi/mi-cmd-stack.c: Use string.h, not gdb_string.h.
* mi/mi-cmd-var.c: Use string.h, not gdb_string.h.
* mi/mi-cmds.c: Use string.h, not gdb_string.h.
* mi/mi-console.c: Use string.h, not gdb_string.h.
* mi/mi-getopt.c: Use string.h, not gdb_string.h.
* mi/mi-interp.c: Use string.h, not gdb_string.h.
* mi/mi-main.c: Use string.h, not gdb_string.h.
* mi/mi-parse.c: Use string.h, not gdb_string.h.
* microblaze-rom.c: Use string.h, not gdb_string.h.
* microblaze-tdep.c: Use string.h, not gdb_string.h.
* mingw-hdep.c: Use string.h, not gdb_string.h.
* minidebug.c: Use string.h, not gdb_string.h.
* minsyms.c: Use string.h, not gdb_string.h.
* mips-irix-tdep.c: Use string.h, not gdb_string.h.
* mips-linux-tdep.c: Use string.h, not gdb_string.h.
* mips-tdep.c: Use string.h, not gdb_string.h.
* mips64obsd-tdep.c: Use string.h, not gdb_string.h.
* mipsnbsd-tdep.c: Use string.h, not gdb_string.h.
* mipsread.c: Use string.h, not gdb_string.h.
* mn10300-linux-tdep.c: Use string.h, not gdb_string.h.
* mn10300-tdep.c: Use string.h, not gdb_string.h.
* monitor.c: Use string.h, not gdb_string.h.
* moxie-tdep.c: Use string.h, not gdb_string.h.
* mt-tdep.c: Use string.h, not gdb_string.h.
* nbsd-tdep.c: Use string.h, not gdb_string.h.
* nios2-linux-tdep.c: Use string.h, not gdb_string.h.
* nto-procfs.c: Use string.h, not gdb_string.h.
* nto-tdep.c: Use string.h, not gdb_string.h.
* objc-lang.c: Use string.h, not gdb_string.h.
* objfiles.c: Use string.h, not gdb_string.h.
* opencl-lang.c: Use string.h, not gdb_string.h.
* osabi.c: Use string.h, not gdb_string.h.
* osdata.c: Use string.h, not gdb_string.h.
* p-exp.y: Use string.h, not gdb_string.h.
* p-lang.c: Use string.h, not gdb_string.h.
* p-typeprint.c: Use string.h, not gdb_string.h.
* parse.c: Use string.h, not gdb_string.h.
* posix-hdep.c: Use string.h, not gdb_string.h.
* ppc-linux-nat.c: Use string.h, not gdb_string.h.
* ppc-sysv-tdep.c: Use string.h, not gdb_string.h.
* ppcfbsd-tdep.c: Use string.h, not gdb_string.h.
* ppcnbsd-tdep.c: Use string.h, not gdb_string.h.
* ppcobsd-tdep.c: Use string.h, not gdb_string.h.
* printcmd.c: Use string.h, not gdb_string.h.
* procfs.c: Use string.h, not gdb_string.h.
* prologue-value.c: Use string.h, not gdb_string.h.
* python/py-auto-load.c: Use string.h, not gdb_string.h.
* python/py-gdb-readline.c: Use string.h, not gdb_string.h.
* ravenscar-thread.c: Use string.h, not gdb_string.h.
* regcache.c: Use string.h, not gdb_string.h.
* registry.c: Use string.h, not gdb_string.h.
* remote-fileio.c: Use string.h, not gdb_string.h.
* remote-m32r-sdi.c: Use string.h, not gdb_string.h.
* remote-mips.c: Use string.h, not gdb_string.h.
* remote-sim.c: Use string.h, not gdb_string.h.
* remote.c: Use string.h, not gdb_string.h.
* reverse.c: Use string.h, not gdb_string.h.
* rs6000-aix-tdep.c: Use string.h, not gdb_string.h.
* ser-base.c: Use string.h, not gdb_string.h.
* ser-go32.c: Use string.h, not gdb_string.h.
* ser-mingw.c: Use string.h, not gdb_string.h.
* ser-pipe.c: Use string.h, not gdb_string.h.
* ser-tcp.c: Use string.h, not gdb_string.h.
* ser-unix.c: Use string.h, not gdb_string.h.
* serial.c: Use string.h, not gdb_string.h.
* sh-tdep.c: Use string.h, not gdb_string.h.
* sh64-tdep.c: Use string.h, not gdb_string.h.
* shnbsd-tdep.c: Use string.h, not gdb_string.h.
* skip.c: Use string.h, not gdb_string.h.
* sol-thread.c: Use string.h, not gdb_string.h.
* solib-dsbt.c: Use string.h, not gdb_string.h.
* solib-frv.c: Use string.h, not gdb_string.h.
* solib-osf.c: Use string.h, not gdb_string.h.
* solib-spu.c: Use string.h, not gdb_string.h.
* solib-target.c: Use string.h, not gdb_string.h.
* solib.c: Use string.h, not gdb_string.h.
* somread.c: Use string.h, not gdb_string.h.
* source.c: Use string.h, not gdb_string.h.
* sparc-nat.c: Use string.h, not gdb_string.h.
* sparc-sol2-tdep.c: Use string.h, not gdb_string.h.
* sparc-tdep.c: Use string.h, not gdb_string.h.
* sparc64-tdep.c: Use string.h, not gdb_string.h.
* sparc64fbsd-tdep.c: Use string.h, not gdb_string.h.
* sparc64nbsd-tdep.c: Use string.h, not gdb_string.h.
* sparcnbsd-tdep.c: Use string.h, not gdb_string.h.
* spu-linux-nat.c: Use string.h, not gdb_string.h.
* spu-multiarch.c: Use string.h, not gdb_string.h.
* spu-tdep.c: Use string.h, not gdb_string.h.
* stabsread.c: Use string.h, not gdb_string.h.
* stack.c: Use string.h, not gdb_string.h.
* std-regs.c: Use string.h, not gdb_string.h.
* symfile.c: Use string.h, not gdb_string.h.
* symmisc.c: Use string.h, not gdb_string.h.
* symtab.c: Use string.h, not gdb_string.h.
* target.c: Use string.h, not gdb_string.h.
* thread.c: Use string.h, not gdb_string.h.
* tilegx-linux-nat.c: Use string.h, not gdb_string.h.
* tilegx-tdep.c: Use string.h, not gdb_string.h.
* top.c: Use string.h, not gdb_string.h.
* tracepoint.c: Use string.h, not gdb_string.h.
* tui/tui-command.c: Use string.h, not gdb_string.h.
* tui/tui-data.c: Use string.h, not gdb_string.h.
* tui/tui-disasm.c: Use string.h, not gdb_string.h.
* tui/tui-file.c: Use string.h, not gdb_string.h.
* tui/tui-layout.c: Use string.h, not gdb_string.h.
* tui/tui-out.c: Use string.h, not gdb_string.h.
* tui/tui-regs.c: Use string.h, not gdb_string.h.
* tui/tui-source.c: Use string.h, not gdb_string.h.
* tui/tui-stack.c: Use string.h, not gdb_string.h.
* tui/tui-win.c: Use string.h, not gdb_string.h.
* tui/tui-windata.c: Use string.h, not gdb_string.h.
* tui/tui-winsource.c: Use string.h, not gdb_string.h.
* typeprint.c: Use string.h, not gdb_string.h.
* ui-file.c: Use string.h, not gdb_string.h.
* ui-out.c: Use string.h, not gdb_string.h.
* user-regs.c: Use string.h, not gdb_string.h.
* utils.c: Use string.h, not gdb_string.h.
* v850-tdep.c: Use string.h, not gdb_string.h.
* valarith.c: Use string.h, not gdb_string.h.
* valops.c: Use string.h, not gdb_string.h.
* valprint.c: Use string.h, not gdb_string.h.
* value.c: Use string.h, not gdb_string.h.
* varobj.c: Use string.h, not gdb_string.h.
* vax-tdep.c: Use string.h, not gdb_string.h.
* vaxnbsd-tdep.c: Use string.h, not gdb_string.h.
* vaxobsd-tdep.c: Use string.h, not gdb_string.h.
* windows-nat.c: Use string.h, not gdb_string.h.
* xcoffread.c: Use string.h, not gdb_string.h.
* xml-support.c: Use string.h, not gdb_string.h.
* xstormy16-tdep.c: Use string.h, not gdb_string.h.
* xtensa-linux-nat.c: Use string.h, not gdb_string.h.
Before all this stop_soon handling, we have code that can end in
keep_going. Particularly, the thread_hop_needed code looked
suspicious considering breakpoint always-inserted mode, though on
closer inspection, it'd take connecting to multiple remote targets
that shared the same address space to trigger that.
Still, I think it's clearer if all this remote connection setup /
attach code is placed early, before any keep_going path could be
reached.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop): Move STOP_QUIETLY,
STOP_QUIETLY_REMOTE and 'stop_after_trap' handling earlier.
After the previous patches, we only ever reach the code after the
initial 'switch (ecs->ws.kind)' switch for TARGET_WAITKIND_STOPPED.
We can now factor out all that to its own function.
Unfortunately, stepped_after_stopped_by_watchpoint needed to move to
the ecs. I think that indicates a state machine bug -- no event other
than TARGET_WAITKIND_STOPPED indicates a single-step actually
finished. TARGET_WAITKIND_SYSCALL_XXX, TARGET_WAITKIND_FORK, etc. are
all events that are triggered from the kernel, _within_ a syscall,
IOW, from userspace's perspective, halfway through an instruction
being executed. This might actually matter for the syscall events, as
syscalls can change memory (and thus trigger watchpoints).
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (struct execution_control_state)
<stepped_after_stopped_by_watchpoint>: New field.
(get_inferior_stop_soon): New function.
(handle_inferior_event): 'stepped_after_stopped_by_watchpoint' was
moved to struct execution_control_state -- adjust. Use
get_inferior_stop_soon. Split TARGET_WAITKIND_STOPPED handling to
new function.
(handle_signal_stop): New function, factored out from
handle_inferior_event.
After the previous patch, there's actually no breakpoint type that
returns BPSTAT_SIGNAL_HIDE, so we can go back to having
bpstat_explains_signal return a boolean. The signal hiding actually
disappears.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* break-catch-sig.c (signal_catchpoint_explains_signal): Adjust to
return a boolean.
* breakpoint.c (bpstat_explains_signal): Adjust to return a
boolean.
(explains_signal_watchpoint, base_breakpoint_explains_signal):
Adjust to return a boolean.
* breakpoint.h (enum bpstat_signal_value): Delete.
(struct breakpoint_ops) <explains_signal>: New returns a boolean.
(bpstat_explains_signal): Likewise.
* infrun.c (handle_inferior_event) <random signal checks>:
bpstat_explains_signal now returns a boolean - adjust. No longer
consider hiding signals.
Looking at the current random signal checks:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
random_signal
= !((bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
GDB_SIGNAL_TRAP)
!= BPSTAT_SIGNAL_NO)
|| stopped_by_watchpoint
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
else
{
enum bpstat_signal_value sval;
sval = bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
ecs->event_thread->suspend.stop_signal);
random_signal = (sval == BPSTAT_SIGNAL_NO);
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
}
We can observe:
- the stepping checks bit:
...
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
...
is just like currently_stepping:
static int
currently_stepping (struct thread_info *tp)
{
return ((tp->control.step_range_end
&& tp->control.step_resume_breakpoint == NULL)
|| tp->control.trap_expected
|| bpstat_should_step ());
}
except it misses the bpstat_should_step check (***).
It's not really necessary to check bpstat_should_step in the
random signal tests, because software watchpoints always end up in
the bpstat list anyway, which means bpstat_explains_signal with
GDB_SIGNAL_TRAP always returns at least BPSSTAT_SIGNAL_HIDE, but I
think the code is clearer if we reuse currently_stepping.
*** - bpstat_should_step checks to see if there's any software
watchpoint in the breakpoint list, because we need to force the
target to single-step all the way, to evaluate the watchpoint's
value at each step.
- we never hide GDB_SIGNAL_TRAP, even if the bpstat returns
BPSTAT_SIGNAL_HIDE, which is actually the default for all
breakpoints. If we make the default be BPSTAT_SIGNAL_PASS, then
we can merge the two bpstat_explains_signal paths.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_explains_signal) <Moribund locations>:
Return BPSTAT_SIGNAL_PASS instead of BPSTAT_SIGNAL_HIDE.
(explains_signal_watchpoint): Return BPSTAT_SIGNAL_PASS instead of
BPSTAT_SIGNAL_HIDE.
(base_breakpoint_explains_signal): Return BPSTAT_SIGNAL_PASS
instead of BPSTAT_SIGNAL_HIDE.
* infrun.c (handle_inferior_event): Rework random signal checks.
This goes a step forward in making only TARGET_WAITKIND_STOPPED talk
about signals.
There's no reason for the "catchpoint" TARGET_WAITKIND_XXXs to consult
bpstat about signals -- unlike breakpoints, all these events are
continuable, so we don't need to do a remove-break/step/reinsert-break
-like dance. That means we don't actually need to run them through
process_event_stop_test (for the bpstat_what checks), and can just use
bpstat_causes_stop instead. Note we were already using it in the
TARGET_WAITKIND_(V)FORKED cases.
Then, these "catchpoint" waitkinds don't need to set
ecs->random_signal for anything, because they check it immediately
afterwards (and the value they set is never used again).
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (struct execution_control_state): Remove
'random_signal' field.
(handle_syscall_event): Use bpstat_causes_stop instead of
bpstat_explains_signal. Don't set ecs->random_signal.
(handle_inferior_event): New 'random_signal' local.
<TARGET_WAITKIND_FORKED, TARGET_WAITKIND_VFORKED,
TARGET_WAITKIND_EXECD>: Use bpstat_causes_stop instead of
bpstat_explains_signal. Don't set ecs->random_signal.
<TARGET_WAITKIND_STOPPED>: Adjust to use local instead of
ecs->random_signal.
This comment applies to the whole handle_inferior_event flow, top to
bottom. Best move it to the function's intro.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): Move comment from the
function's body to the function's description, adjusted.
Of all the TARGET_WAITKIND_XXXs event kinds other than
TARGET_WAITKIND_STOPPED, TARGET_WAITKIND_LOADED is the only kind that
doesn't end in a return, instead falling through to all the
signal/breakpoint/stepping handling code. But it only falls through
in the STOP_QUIETLY_NO_SIGSTOP and STOP_QUIETLY_REMOTE cases, which
means the
/* This is originated from start_remote(), start_inferior() and
shared libraries hook functions. */
if (stop_soon == STOP_QUIETLY || stop_soon == STOP_QUIETLY_REMOTE)
{
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: quietly stopped\n");
stop_stepping (ecs);
return;
}
bit is eventually reached. All tests before that is reached will
always fail. It's simpler to inline the stop_soon checks close to the
TARGET_WAITKIND_LOADED code, which allows removing the fall through.
Tested on x86_64 Fedora 17, but that doesn't exercise this
TARGET_WAITKIND_LOADED.
Also ran gdb.base/solib-disc.exp on Cygwin/gdbserver, which exercises
reconnection while the inferior is stopped at an solib event, but then
again, gdbserver always replies a regular trap on initial connection,
instead of the last event the program had seen:
Sending packet: $?#3f...Packet received: T0505:4ca72800;04:f8a62800;08:62fcc877;thread:d28;
Sending packet: $Hc-1#09...Packet received: E01
Sending packet: $qAttached#8f...Packet received: 0
Packet qAttached (query-attached) is supported
infrun: clear_proceed_status_thread (Thread 3368)
Sending packet: $qOffsets#4b...Packet received:
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 42000 [Thread 3368],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x77c8fc62
infrun: quietly stopped
infrun: stop_stepping
So the only way to exercise this would be to hack gdbserver. I didn't
go that far though. I'm reasonably confident this is correct.
gdb/
2013-11-14 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
Handle STOP_QUIETLY_NO_SIGSTOP and STOP_QUIETLY_REMOTE here.
Assert we never fall through out of the TARGET_WAITKIND_LOADED
case.
IMO, it doesn't make sense to map random syscall, fork, etc. events to
GDB_SIGNAL_TRAP, and possible have the debuggee see that trap. This
just seems conceptually wrong to me - these aren't real signals a
debuggee would ever see. In fact, when stopped for those events, on
Linux, the debuggee isn't in a signal-stop -- there's no way to
resume-and-deliver-signal at that point, for example. E.g., when
stopped at a fork event:
(gdb) catch fork
Catchpoint 2 (fork)
(gdb) c
Continuing.
Catchpoint 2 (forked process 4570), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) set debug infrun 1
(gdb) signal SIGTRAP
Continuing with signal SIGTRAP.
infrun: clear_proceed_status_thread (process 4566)
infrun: proceed (addr=0xffffffffffffffff, signal=5, step=0)
infrun: resume (step=0, signal=5), trap_expected=0, current thread [process 4566] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4566 [process 4566],
infrun: status->kind = exited, status = 0
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_EXITED
[Inferior 1 (process 4566) exited normally]
infrun: stop_stepping
(gdb)
Note the signal went nowhere. It was swallowed.
Resuming with a SIGTRAP from a syscall event does queue the signal,
but doesn't deliver it immediately, like "signal SIGTRAP" from a real
signal would. It's still an artificial SIGTRAP:
(gdb) catch syscall
Catchpoint 2 (any syscall)
(gdb) c
Continuing.
Catchpoint 2 (call to syscall clone), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) set debug infrun 1
(gdb) signal SIGTRAP
Continuing with signal SIGTRAP.
infrun: clear_proceed_status_thread (process 4622)
infrun: proceed (addr=0xffffffffffffffff, signal=5, step=0)
infrun: resume (step=0, signal=5), trap_expected=0, current thread [process 4622] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4622 [process 4622],
infrun: status->kind = exited syscall
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_SYSCALL_RETURN
infrun: syscall number = '56'
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping
Catchpoint 2 (returned from syscall clone), 0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (process 4622)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0, current thread [process 4622] at 0x323d4ba7c4
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 4622 [process 4622],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4ba7c4
infrun: random signal 5
Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping
0x000000323d4ba7c4 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:131
131 pid = ARCH_FORK ();
(gdb)
In all the above, I used 'signal SIGTRAP' to emulate 'handle SIGTRAP
pass'. As described in "keep_going", 'handle SIGTRAP pass' does have
its place:
/* Do not deliver GDB_SIGNAL_TRAP (except when the user
explicitly specifies that such a signal should be delivered
to the target program). Typically, that would occur when a
user is debugging a target monitor on a simulator: the target
monitor sets a breakpoint; the simulator encounters this
breakpoint and halts the simulation handing control to GDB;
GDB, noting that the stop address doesn't map to any known
breakpoint, returns control back to the simulator; the
simulator then delivers the hardware equivalent of a
GDB_SIGNAL_TRAP to the program being debugged. */
... and I've made use of that myself when implementing/debugging
stubs/monitors. But in these cases, treating these events as SIGTRAP
possibly injects signals in the debuggee they'd never see otherwise,
because you need to use ptrace to enable these special events, which
aren't real signals.
There's more. Take this bit of handle_inferior_event, where we
determine whether a real signal (TARGET_WAITKIND_STOPPED) was random
or not:
if (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP)
ecs->random_signal
= !((bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
GDB_SIGNAL_TRAP)
!= BPSTAT_SIGNAL_NO)
|| stopped_by_watchpoint
|| ecs->event_thread->control.trap_expected
|| (ecs->event_thread->control.step_range_end
&& (ecs->event_thread->control.step_resume_breakpoint
== NULL)));
else
{
enum bpstat_signal_value sval;
sval = bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
ecs->event_thread->suspend.stop_signal);
ecs->random_signal = (sval == BPSTAT_SIGNAL_NO);
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_TRAP;
}
Note that the
if (sval == BPSTAT_SIGNAL_HIDE)
ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_TRAP;
bit is only reacheable for signals != GDB_SIGNAL_TRAP. AFAICS, sval
can only be BPSTAT_SIGNAL_HIDE if nothing in the bpstat returns
BPSTAT_SIGNAL_PASS. So that excludes a "catch signal" for the signal
in question in the bpstat. All other catchpoints that aren't based on
breakpoints behind the scenes call process_event_stop_test directly
(don't pass through here) (well, almost all: TARGET_WAITKIND_LOADED
does have a fall through, but only for STOP_QUIETLY or
STOP_QUIETLY_NO_SIGSTOP, which still return before this code is
reached). Catchpoints that are implemented as breakpoints behind the
scenes can only appear in the bpstat if the signal was GDB_SIGNAL_TRAP
(bkpt_breakpoint_hit returns false otherwise). So that leaves a
target reporting a hardware watchpoint hit with a signal other than
GDB_SIGNAL_TRAP. And even then it looks quite wrong to me to
magically convert the signal into a GDB_SIGNAL_TRAP here too -- if the
user has set SIGTRAP to "handle pass", the program will see a trap
that gdb invented, not one the program would ever see without gdb in
the picture.
Tested on x86_64 Fedora 17.
gdb/
2013-10-31 Pedro Alves <palves@redhat.com>
* infrun.c (handle_syscall_event): Don't set or clear stop_signal.
(handle_inferior_event) <TARGET_WAITKIND_FORKED,
TARGET_WAITKIND_VFORKED>: Don't set stop_signal to
GDB_SIGNAL_TRAP, or clear it. Pass GDB_SIGNAL_0 to
bpstat_explains signal, instead of GDB_SIGNAL_TRAP.
<bpstat handling>: If the bpstat chain wants the signal to be
hidden, then set stop_signal to GDB_SIGNAL_0 instead of
GDB_SIGNAL_TRAP.
Now that all ecs->random_signal handing is always done before the
'process_event_stop_test' label, we can easily make that a real
function and actually give it a describing comment that somewhat makes
sense.
Reindenting the new function will be handled in a follow up patch.
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (process_event_stop_test): New function, factored out
from handle_inferior_event.
(handle_inferior_event): 'process_event_stop_test' is now a
function instead of a goto label -- adjust.
We only ever call "goto process_event_stop_test;" right after checking
that ecs->random_signal is clear. The code at the
process_event_stop_test label looks like:
/* For the program's own signals, act according to
the signal handling tables. */
if (ecs->random_signal)
{
... random signal handling ...
return;
}
else
{
... the stop tests that actually matter for the goto callers.
}
So this moves the label into the else branch. It'll make converting
process_event_stop_test into a function a bit clearer.
gdb/
2013-10-28 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): Move process_event_stop_test
goto label to the else branch of the ecs->random_signal check,
along with FRAME and GDBARCH re-fetching.
Gary Benson
Pedro Alves
Yao Qi
Tom Tromey
Luis Machado
Simon Marchi
Doug Evans
Hui Zhu
Ulrich Weigand
Markus Metzger
Joel Brobecker