gdb and binutils branch master updated. 36fa80421a9edbf97fc6081557509937bc717bc1
palves@sourceware.org
palves@sourceware.org
Thu Nov 14 20:21:00 GMT 2013
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 <palves@redhat.com>
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 <palves@redhat.com>
* 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 <palves@redhat.com>
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 <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.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=47591c29add16c520c7bc2c7ace227deeb08f4a5
commit 47591c29add16c520c7bc2c7ace227deeb08f4a5
Author: Pedro Alves <palves@redhat.com>
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 <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.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bac7d97b66867e7654a1c27b00e7164e24243da0
commit bac7d97b66867e7654a1c27b00e7164e24243da0
Author: Pedro Alves <palves@redhat.com>
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 <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.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ce12b0125d49c4c47813f010c8d60d4c79ff52e1
commit ce12b0125d49c4c47813f010c8d60d4c79ff52e1
Author: Pedro Alves <palves@redhat.com>
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 <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.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=05ba85103b9131333b829c7c1366bfdb015169a3
commit 05ba85103b9131333b829c7c1366bfdb015169a3
Author: Pedro Alves <palves@redhat.com>
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 <palves@redhat.com>
* 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 <palves@redhat.com>
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 <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.
-----------------------------------------------------------------------
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
More information about the Src-cvs
mailing list