From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15901 invoked by alias); 14 Nov 2013 20:21:29 -0000 Mailing-List: contact src-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: src-cvs-owner@sourceware.org Received: (qmail 15787 invoked by uid 9683); 14 Nov 2013 20:21:26 -0000 Date: Thu, 14 Nov 2013 20:21:00 -0000 Message-ID: <20131114202123.15660.qmail@sourceware.org> From: palves@sourceware.org To: src-cvs@sourceware.org Subject: gdb and binutils branch master updated. 36fa80421a9edbf97fc6081557509937bc717bc1 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 94e49e160d0c3f0b1b838f9963b1da5d3cfc795b X-Git-Newrev: 36fa80421a9edbf97fc6081557509937bc717bc1 X-SW-Source: 2013-q4/txt/msg00161.txt.bz2 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 36fa80421a9edbf97fc6081557509937bc717bc1 (commit) via 4f5d7f635cd1dd81575edb35395272ee3d535502 (commit) via 47591c29add16c520c7bc2c7ace227deeb08f4a5 (commit) via bac7d97b66867e7654a1c27b00e7164e24243da0 (commit) via ce12b0125d49c4c47813f010c8d60d4c79ff52e1 (commit) via 05ba85103b9131333b829c7c1366bfdb015169a3 (commit) via 5c09a2c53c3d3259392ada37303af8033ab91c7e (commit) from 94e49e160d0c3f0b1b838f9963b1da5d3cfc795b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=36fa80421a9edbf97fc6081557509937bc717bc1 commit 36fa80421a9edbf97fc6081557509937bc717bc1 Author: Pedro Alves Date: Thu Nov 14 19:43:27 2013 +0000 infrun.c:handle_signal_stop: Move initial connection/attachment handling code earlier. 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 * infrun.c (handle_signal_stop): Move STOP_QUIETLY, STOP_QUIETLY_REMOTE and 'stop_after_trap' handling earlier. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4f5d7f635cd1dd81575edb35395272ee3d535502 commit 4f5d7f635cd1dd81575edb35395272ee3d535502 Author: Pedro Alves Date: Thu Nov 14 19:43:27 2013 +0000 infrun.c: Split handle_inferior_event further. 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 * infrun.c (struct execution_control_state) : 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. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=47591c29add16c520c7bc2c7ace227deeb08f4a5 commit 47591c29add16c520c7bc2c7ace227deeb08f4a5 Author: Pedro Alves Date: Thu Nov 14 19:43:27 2013 +0000 Eliminate enum bpstat_signal_value, simplify random signal checks further. 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 * 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) : New returns a boolean. (bpstat_explains_signal): Likewise. * infrun.c (handle_inferior_event) : bpstat_explains_signal now returns a boolean - adjust. No longer consider hiding signals. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bac7d97b66867e7654a1c27b00e7164e24243da0 commit bac7d97b66867e7654a1c27b00e7164e24243da0 Author: Pedro Alves Date: Thu Nov 14 19:43:26 2013 +0000 infrun.c:handle_inferior_event: Rework random signal checks. 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 * breakpoint.c (bpstat_explains_signal) : 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. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ce12b0125d49c4c47813f010c8d60d4c79ff52e1 commit ce12b0125d49c4c47813f010c8d60d4c79ff52e1 Author: Pedro Alves Date: Thu Nov 14 19:43:26 2013 +0000 infrun.c: Don't set ecs->random_signal for "catchpoint" events (eliminate ecs->random_signal). 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 * 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. : Use bpstat_causes_stop instead of bpstat_explains_signal. Don't set ecs->random_signal. : Adjust to use local instead of ecs->random_signal. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=05ba85103b9131333b829c7c1366bfdb015169a3 commit 05ba85103b9131333b829c7c1366bfdb015169a3 Author: Pedro Alves Date: Thu Nov 14 19:43:25 2013 +0000 infrun.c:handle_inferior_event: Move comment. 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 * infrun.c (handle_inferior_event): Move comment from the function's body to the function's description, adjusted. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5c09a2c53c3d3259392ada37303af8033ab91c7e commit 5c09a2c53c3d3259392ada37303af8033ab91c7e Author: Pedro Alves Date: Thu Nov 14 19:43:25 2013 +0000 infrun.c:handle_inferior_event: Don't fall through in TARGET_WAITKIND_LOADED handling. 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 * infrun.c (handle_inferior_event) : Handle STOP_QUIETLY_NO_SIGSTOP and STOP_QUIETLY_REMOTE here. Assert we never fall through out of the TARGET_WAITKIND_LOADED case. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 67 ++++++++++++ gdb/break-catch-sig.c | 4 +- gdb/breakpoint.c | 34 +++---- gdb/breakpoint.h | 32 +----- gdb/infrun.c | 285 +++++++++++++++++++++++++------------------------ 5 files changed, 232 insertions(+), 190 deletions(-) hooks/post-receive -- gdb and binutils