public inbox for
help / color / mirror / Atom feed
* gdb and binutils branch master updated. 36fa80421a9edbf97fc6081557509937bc717bc1
@ 2013-11-14 20:21 palves
  0 siblings, 0 replies; only message in thread
From: palves @ 2013-11-14 20:21 UTC (permalink / raw)
  To: src-cvs

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 -----------------------------------------------------------------;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
    2013-11-14  Pedro Alves  <>
    	* infrun.c (handle_signal_stop): Move STOP_QUIETLY,
    	STOP_QUIETLY_REMOTE and 'stop_after_trap' handling earlier.;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
    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).
    2013-11-14  Pedro Alves  <>
    	* 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

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
    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
    	(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.;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)
          = !((bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
    	   != 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)));
          enum bpstat_signal_value sval;
          sval = bpstat_explains_signal (ecs->event_thread->control.stop_bpstat,
          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.
    2013-11-14  Pedro Alves  <>
    	* breakpoint.c (bpstat_explains_signal) <Moribund locations>:
    	(explains_signal_watchpoint): Return BPSTAT_SIGNAL_PASS instead of
    	(base_breakpoint_explains_signal): Return BPSTAT_SIGNAL_PASS
    	instead of BPSTAT_SIGNAL_HIDE.
    	* infrun.c (handle_inferior_event): Rework random signal checks.;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
    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).
    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.
    	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

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.
    2013-11-14  Pedro Alves  <>
    	* infrun.c (handle_inferior_event): Move comment from the
    	function's body to the function's description, adjusted.;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
    doesn't end in a return, instead falling through to all the
    signal/breakpoint/stepping handling code.  But it only falls through
    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);
    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
    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: 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.
    2013-11-14  Pedro Alves  <>
    	* infrun.c (handle_inferior_event) <TARGET_WAITKIND_LOADED>:
    	Assert we never fall through out of the TARGET_WAITKIND_LOADED


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(-)

gdb and binutils

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-11-14 20:21 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-14 20:21 gdb and binutils branch master updated. 36fa80421a9edbf97fc6081557509937bc717bc1 palves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).