This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Use resume instead of target_resume when stepping over watchpoint.


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]