This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Patch] Use resume instead of target_resume when stepping over watchpoint.
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 30 Oct 2008 08:29:33 -0700
- Subject: Re: [Patch] Use resume instead of target_resume when stepping over watchpoint.
- References: <48C71565.3050601@avtrex.com> <20081030030805.GC3635@adacore.com> <200810301222.23864.pedro@codesourcery.com>
[Dave Daney removed from the list, since his email address is no longer
valid. Is it worth pursuing this thread?]
> Won't this slightly change the behaviour on hardware single-step
> archs? Before, we'd always tell the target to resume a single-thread
> (keeping the others stopped, on target that support scheduler locking);
> with this change, I think you'll tell the target to resume all
> threads.
Hmmm, yes, you're probably right. I we were to set trap_expected,
then we would only step that one thread, but would that be cheating?
> be too ugly? Hmmm, maybe not OK, it can have other side
> effects, like tripping on this...
>
> if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP
> && ecs->event_thread->trap_expected
> && gdbarch_single_step_through_delay_p (current_gdbarch)
> && currently_stepping (ecs->event_thread))
I guess we might, if we hit the watchpoint while stepping. But then,
trap_expected would have already been set, and thus we'd be OK without
setting it anyways.
Regardless, I think this just shows that calling resume like this is
just too ugly. Perhaps a better approach would be to extract out the
part that handles software_single_step out of resume and have both
resume & handle_inferior_event call that new function?
--
Joel