aboutsummaryrefslogtreecommitdiff
path: root/gdb/infrun.h
AgeCommit message (Collapse)AuthorFilesLines
2015-08-20remote non-stop: Process initially stopped threads before other commandsPedro Alves1-0/+5
The main motivation for this is making non-stop / all-stop behave similarly on initial connection, in order to move in the direction of reimplementing all-stop mode with the remote target always running in non-stop mode. When we connect to a remote target in non-stop mode, we may find threads either running or already stopped. The act of connecting itself does not force threads to stop. To handle that, the remote non-stop connection is currently roughly like this: #1 - Fetch list of remote threads (qXfer:threads:read, qfThreadInfo, etc). All threads are assumed to be running until the target reports an asynchronous stop reply for them. #2 - Fetch the initial set of threads that were already stopped, with the '?' packet. (In non-stop, this is coupled with the vStopped mechanism to be able to retrieve the status of more than one thread.) The stop replies fetched in #2 are placed in the pending stop reply queue, and left for the regular event loop to process. That is, "target remote" finishes and returns _before_ those stops are processed. That means that it's possible to have GDB process further commands before the initial set of stopped threads is reported to the user. E.g., before the patch, note how the prompt is printed before the frame: Remote debugging using :9999 (gdb) [Thread 15296] #1 stopped. 0x0000003615a011f0 in ?? () Even though thread #1 was not running, for a moment, the user can see it as such: $ gdb a.out -ex "set non-stop 1" -ex "tar rem :9999" -ex "info threads" -ex "info registers" Remote debugging using :9999 Id Target Id Frame * 1 Thread 4772 (running) Target is executing. <<<<<<< info registers (gdb) [Thread 4772] #1 stopped. 0x0000003615a011f0 in ?? () To fix that, this commit makes gdb process all threads found already stopped at connection time, before giving the prompt to the user. The fix takes a cue from fork-child.c:startup_inferior [1], and processes the events locally in remote.c, avoiding the whole wait_for_inferior/handle_inferior_event path. I decided to try this approach after noticing that: - several cases in handle_inferior_event miss checking stop_soon. - we don't want to fetch the thread list in normal_stop. and trying to fix them was resulting in sprinkling stop_soon checks in many places, and uglifying normal_stop even more. While with this patch, I'm avoiding changing GDB's output other than when the prompt is printed, I think this approach is more flexible if we do want to change it. And also, it's likely easier to get rid of the MI *running event that is still sent for threads that are initially found stopped, if we want to. This happens to fix the testsuite too. All non-stop tests are racy against "target remote" / gdbserver testing currently. That is, sometimes the tests run, but other times they're just skipped without any indication of PASS/FAIL. When that happens, the logs show: target remote localhost:2346 Remote debugging using localhost:2346 (gdb) [Thread 25418] #1 stopped. 0x0000003615a011f0 in ?? () ^CQuit (gdb) Remote debugging from host 127.0.0.1 Killing process(es): 25418 monitor exit (gdb) Remote connection closed (gdb) testcase /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/multi-create-ns-info-thr.exp completed in 61 seconds The trouble here is that there's output after the prompt, and the regex in question doesn't expect that: -re "Remote debugging using .*$serialport_re.*$gdb_prompt $" { verbose "Set target to $targetname" return 0 } [1] - before startup_inferior was added, we'd go through wait_for_inferior/handle_inferior_event while going through the shell, and that turned out problematic. Tested on x86_64 Fedora 20, gdbserver. gdb/ChangeLog: 2015-08-20 Pedro Alves <palves@redhat.com> * infrun.c (print_target_wait_results): Make extern. * infrun.h (print_target_wait_results): Declare. * remote.c (set_stop_requested_callback): Delete. (process_initial_stop_replies): New function. (remote_start_remote): Use it. (stop_reply_queue_length): New function. gdb/testsuite/ChangeLog: 2015-08-20 Pedro Alves <palves@redhat.com> * gdb.server/connect-stopped-target.c: New file. * gdb.server/connect-stopped-target.exp: New file.
2015-08-07Teach non-stop to do in-line step-overs (stop all, step, restart)Pedro Alves1-0/+3
That is, step past breakpoints by: - pausing all threads - removing breakpoint at PC - single-step - reinsert breakpoint - restart threads similarly to all-stop (with displaced stepping disabled). This allows non-stop to work on targets/architectures without displaced stepping support. That is, it makes displaced stepping an optimization instead of a requirement. For example, in principle, all GNU/Linux ports support non-stop mode at the target_ops level, but not all corresponding gdbarch's implement displaced stepping. This should make non-stop work for all (albeit, not as efficiently). And then there are scenarios where even if the architecture supports displaced stepping, we can't use it, because we e.g., don't find a usable address to use as displaced step scratch pad. It should also fix stepping past watchpoints on targets that have non-continuable watchpoints in non-stop mode (e.g., PPC, untested). Running the instruction out of line in the displaced stepping scratch pad doesn't help that case, as the copied instruction reads/writes the same watched memory... We can fix that too by teaching GDB to only remove the watchpoint from the thread that we want to move past the watchpoint (currently, removing a watchpoint always removes it from all threads), but again, that can be considered an optimization; not all targets would support it. For those familiar with the gdb and gdbserver Linux target_ops backends, the implementation should look similar, except it is done on the core side. When we pause threads, we may find they stop with an interesting event that should be handled later when the thread is re-resumed, thus we store such events in the thread object, and mark the event as pending. We should only consume pending events if the thread is indeed resumed, thus we add a new "resumed" flag to the thread object. At a later stage, we might add new target methods to accelerate some of this, like "pause all threads", with corresponding RSP packets, but we'd still need a fallback method for remote targets that don't support such packets, so, again, that can be deferred as optimization. My _real_ motivation here is making it possible to reimplement all-stop mode on top of the target always working on non-stop mode, so that e.g., we can send RSP packets to a remote target even while the target is running -- can't do that in the all-stop RSP variant, by design). Tested on x86_64 Fedora 20, with and without "set displaced off" forced. The latter forces the new code paths whenever GDB needs to step past a breakpoint. gdb/ChangeLog: 2015-08-07 Pedro Alves <pedro@codesourcery.com> * breakpoint.c (breakpoints_should_be_inserted_now): If any thread has a pending status, return true. * gdbthread.h: Include target/waitstatus.h. (struct thread_suspend_state) <stop_reason, waitstatus_pending_p, stop_pc>: New fields. (struct thread_info) <resumed>: New field. (set_resumed): Declare. * infrun.c: Include "event-loop.h". (infrun_async_inferior_event_token, infrun_is_async): New globals. (infrun_async): New function. (clear_step_over_info): Add debug output. (displaced_step_in_progress_any_inferior): New function. (displaced_step_fixup): New returns int. (start_step_over): Handle in-line step-overs too. Assert the thread is marked resumed. (resume_cleanups): Clear the thread's resumed flag. (resume): Set the thread's resumed flag. Return early if the thread has a pending status. Allow stepping a breakpoint with no signal. (proceed): Adjust to check 'resumed' instead of 'executing'. (clear_proceed_status_thread): If the thread has a pending status, and that status is a finished step, discard the pending status. (clear_proceed_status): Don't clear step_over_info here. (random_pending_event_thread, do_target_wait): New functions. (prepare_for_detach, wait_for_inferior, fetch_inferior_event): Use do_target_wait. (wait_one): New function. (THREAD_STOPPED_BY): New macro. (thread_stopped_by_watchpoint, thread_stopped_by_sw_breakpoint) (thread_stopped_by_hw_breakpoint): New functions. (switch_to_thread_cleanup, save_waitstatus, stop_all_threads): New functions. (handle_inferior_event): Also call set_resumed(false) on all threads implicitly stopped by the event. (restart_threads, resumed_thread_with_pending_status): New functions. (finish_step_over): If we were doing an in-line step-over before, and no longer are after trying to start a new step-over, restart all threads. If we have multiple threads with pending events, save the current event and go through the event loop again. (handle_signal_stop): Return early if finish_step_over returns false. <random signal>: If we get a signal while stepping over a breakpoint in-line in non-stop mode, restart all threads. Clear step_over_info before delivering the signal. (keep_going_stepped_thread): Use internal_error instead of gdb_assert. Mark the thread as resumed. (keep_going_pass_signal): Assert the thread isn't already resumed. If some other thread is doing an in-line step-over, defer the resume. If we just started a new in-line step-over, stop all threads. Don't clear step_over_info. (infrun_async_inferior_event_handler): New function. (_initialize_infrun): Create async event handler with infrun_async_inferior_event_handler as callback. (infrun_async): New declaration. * target.c (target_async): New function. * target.h (target_async): Declare macro and readd as function declaration. * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. * thread.c (new_thread): Clear the new waitstatus field. (set_resumed): New function.
2015-08-07Embed the pending step-over chain in thread_info objectsPedro Alves1-0/+4
In order to teach non-stop mode to do in-line step-overs (pause all threads, remove breakpoint, single-step, reinsert breakpoint, restart threads), we'll need to be able to queue in-line step over requests, much like we queue displaced stepping (out-of-line) requests. Actually, the queue should be the same -- threads wait for their turn to step past something (breakpoint, watchpoint), doesn't matter what technique we end up using when the step over actually starts. I found that the queue management ends up simpler and more efficient if embedded in the thread objects themselves. This commit converts the existing displaced stepping queue to that. Later patches will make the in-line step-overs code paths use it too. gdb/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * gdbthread.h (struct thread_info) <step_over_prev, step_over_next>: New fields. (thread_step_over_chain_enqueue, thread_step_over_chain_remove) (thread_step_over_chain_next, thread_is_in_step_over_chain): New declarations. * infrun.c (struct displaced_step_request): Delete. (struct displaced_step_inferior_state) <step_request_queue>: Delete field. (displaced_step_prepare): Assert that trap_expected is set. Use thread_step_over_chain_enqueue. Split starting a new displaced step to ... (start_step_over): ... this new function. (resume): Assert the thread isn't waiting for a step over already. (proceed): Assert the thread isn't waiting for a step over already. (infrun_thread_stop_requested): Adjust to remove threads from the embedded step-over chain. (handle_inferior_event) <fork/vfork>: Call start_step_over after displaced_step_fixup. (handle_signal_stop): Call start_step_over after displaced_step_fixup. * infrun.h (step_over_queue_head): New declaration. * thread.c (step_over_chain_enqueue, step_over_chain_remove) (thread_step_over_chain_next, thread_is_in_step_over_chain) (thread_step_over_chain_enqueue) (thread_step_over_chain_remove): New functions. (delete_thread_1): Remove thread from the step-over chain.
2015-05-13Remove stop_registersJan Kratochvil1-7/+0
Now stop_registers are no longer used and it can be removed. I am not much sure what 'proceed_to_finish' really means now so I make a wild guess while updating comments about it. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * gdbthread.h (struct thread_control_state): Update comment for proceed_to_finish. * infcall.c (run_inferior_call): Update comment about proceed_to_finish. * infcmd.c (get_return_value): Update comment about stop_registers. (finish_forward): Update comment about proceed_to_finish. * infrun.c (stop_registers): Remove. (clear_proceed_status, normal_stop): Remove stop_registers handling. * infrun.h (stop_registers): Remove.
2015-03-24Shuffle user_visible_resume_ptidPedro Alves1-1/+7
... and move comment to declaration. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * infrun.c (user_visible_resume_ptid): Rewrite going from most-locked to unlocked instead of the opposite. Move comment ... * infrun.h (user_visible_resume_ptid): ... here.
2015-03-24Remove 'step' parameters from 'proceed' and 'resume'Pedro Alves1-2/+2
The "step" parameters of 'proceed' and 'resume' aren't really useful as indication of whether run control wants to single-step the target, as that information must already be retrievable from currently_stepping. In fact, if currently_stepping disagrees with whether we single-stepped the target, then things break. Thus instead of having the same information in two places, this patch removes those parameters. Setting 'step_start_function' is the only user of proceed's 'step' argument, other than passing the 'step' argument down to 'resume' and debug log output. Move that instead to set_step_frame, where we already set other related fields. clear_proceed_status keeps its "step" parameter for now because it needs to know which set of threads should have their state cleared, and is called before the "stepping_command" flag is set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves <palves@redhat.com> * breakpoint.c (until_break_command): Adjust call to proceed. * gdbthread.h (struct thread_control_state) <stepping_command>: New field. * infcall.c (run_inferior_call): Adjust call to proceed. * infcmd.c (run_command_1, proceed_thread_callback, continue_1): Adjust calls to proceed. (set_step_frame): Set the current thread's step_start_function here. (step_once): Adjust calls to proceed. (jump_command, signal_command, until_next_command) (finish_backward, finish_forward, proceed_after_attach_callback) (attach_command_post_wait): Adjust calls to proceed. * infrun.c (proceed_after_vfork_done): Adjust call to proceed. (do_target_resume): New function, factored out from ... (resume): ... here. Remove 'step' parameter. Instead, check currently_stepping to determine whether the thread should be single-stepped. (proceed): Remove 'step' parameter and don't set the thread's step_start_function here. Adjust call to 'resume'. (handle_inferior_event): Adjust calls to 'resume'. (switch_back_to_stepped_thread): Use do_target_resume instead of 'resume'. (keep_going): Adjust calls to 'resume'. * infrun.h (proceed): Remove 'step' parameter. (resume): Likewise. * windows-nat.c (do_initial_windows_stuff): Adjust call to 'resume'. * mi/mi-main.c (proceed_thread): Adjust call to 'proceed'.
2015-01-01Update year range in copyright notice of all files owned by the GDB project.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2014-10-15Rewrite non-continuable watchpoints handlingPedro Alves1-0/+4
When GDB finds out the target triggered a watchpoint, and the target has non-continuable watchpoints, GDB sets things up to step past the instruction that triggered the watchpoint. This is just like stepping past a breakpoint, but goes through a different mechanism - it resumes only the thread that needs to step past the watchpoint, but also switches a "infwait state" global, that has the effect that the next target_wait only wait for events only from that thread. This forcing of a ptid to pass to target_wait obviously becomes a bottleneck if we ever support stepping past different watchpoints simultaneously (in separate processes). It's also unnecessary -- the target should only return events for threads that have been resumed; if no other thread than the one we're stepping past the watchpoint has been resumed, then those other threads should not report events. If we couldn't assume that, then stepping past regular breakpoints would be broken for not likewise forcing a similar infwait_state. So this patch eliminates infwait_state, and instead teaches keep_going to mark step_over_info in a way that has the breakpoints module skip inserting watchpoints (because we're stepping past one), like it skips breakpoints when we're stepping past one. Tested on: - x86_64 Fedora 20 (continuable watchpoints) - PPC64 Fedora 18 (non-steppable watchpoints) gdb/ 2014-10-15 Pedro Alves <palves@redhat.com> * breakpoint.c (should_be_inserted): Don't insert watchpoints if trying to step past a non-steppable watchpoint. * gdbthread.h (struct thread_info) <stepping_over_watchpoint>: New field. * infrun.c (struct step_over_info): Add new field 'nonsteppable_watchpoint_p' and adjust comments. (set_step_over_info): New 'nonsteppable_watchpoint_p' parameter. Adjust. (clear_step_over_info): Clear nonsteppable_watchpoint_p as well. (stepping_past_nonsteppable_watchpoint): New function. (step_over_info_valid_p): Also return true if stepping past a nonsteppable watchpoint. (proceed): Adjust call to set_step_over_info. Remove reference to init_infwait_state. (init_wait_for_inferior): Remove reference to init_infwait_state. (waiton_ptid): Delete global. (struct execution_control_state) <stepped_after_stopped_by_watchpoint>: Delete field. (wait_for_inferior, fetch_inferior_event): Always pass minus_one_ptid to target_wait. (init_thread_stepping_state): Clear 'stepping_over_watchpoint' field. (init_infwait_state): Delete function. (handle_inferior_event): Remove infwait_state handling. (handle_signal_stop) <watchpoints handling>: Adjust after stepped_after_stopped_by_watchpoint removal. Don't remove breakpoints here nor set infwait_state. Set the thread's stepping_over_watchpoint flag, and call keep_going instead. (keep_going): Handle stepping_over_watchpoint. Adjust set_step_over_info calls. * infrun.h (stepping_past_nonsteppable_watchpoint): Declare function.
2014-09-30Refactor native follow-fork.Don Breazeal1-2/+0
This patch reorganizes the code that implements follow-fork and detach-on-fork in preparation for implementation of those features for the extended-remote target. The function linux-nat.c:linux_child_follow_fork contained target-independent code mixed in with target-dependent code. The target-independent pieces need to be accessible for the host-side implementation of follow-fork for extended-remote Linux targets. The changes are fairly mechanical. A new routine, follow_fork_inferior, is implemented in infrun.c, containing those parts of linux_child_follow_fork that manage inferiors and the inferior list. The parts of linux_child_follow_fork that deal with LWPs and target-specifics were left in-place. Although the order of some operations was changed, the resulting functionality was not. Modifications were made to the other native target follow-fork functions, inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them to work with follow_fork_inferior. Some other adjustments were necessary in inf-ttrace.c. The changes to inf-ttrace.c and inf-ptrace.c were not tested. gdb/ChangeLog: * inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent code so as to work with follow_fork_inferior. * inf-ttrace.c (inf_ttrace_follow_fork): Ditto. (inf_ttrace_create_inferior): Remove reference to inf_ttrace_vfork_ppid. (inf_ttrace_attach): Ditto. (inf_ttrace_detach): Ditto. (inf_ttrace_kill): Use current_inferior instead of inf_ttrace_vfork_ppid. (inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the inferior away from the parent. * infrun.c (follow_fork): Call follow_fork_inferior instead of target_follow_fork. (follow_fork_inferior): New function. (follow_inferior_reset_breakpoints): Make function static. * infrun.h (follow_inferior_reset_breakpoints): Remove declaration. * linux-nat.c (linux_child_follow_fork): Move target-independent code to infrun.c:follow_fork_inferior.
2014-08-07Move ptid.h to common-defs.hGary Benson1-1/+0
This commit moves the inclusion of ptid.h to common-defs.h and removes all other inclusions. gdb/ 2014-08-07 Gary Benson <gbenson@redhat.com> * common/common-defs.h: Include ptid.h. * defs.h: Do not include ptid.h. * inferior.h: Likewise. * infrun.h: Likewise. * nat/linux-btrace.h: Likewise. * nat/linux-osdata.h: Likewise. * target/waitstatus.h: Likewise. gdb/gdbserver/ 2014-08-07 Gary Benson <gbenson@redhat.com> * server.h: Do not include ptid.h. * notif.h: Likewise.
2014-07-25Always pass signals to the right threadPedro Alves1-1/+7
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.
2014-05-29PR gdb/13860 - Make MI sync vs async output (closer to) the same.Pedro Alves1-0/+22
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.
2014-05-22Add new infrun.h header.Pedro Alves1-0/+164
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.