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.


Joel Brobecker wrote:
[Dave Daney removed from the list, since his email address is no longer
valid. Is it worth pursuing this thread?]


It turns out that I am now subscribed under my new e-mail address. But thanks to Tom Tromey for pinging me on this message.


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?


I agree, and in the first version of the patch I hacked something together that kind of did it that way, but it was not very clean.


Now that the MIPS hardware watch register support is merged into the Linux kernel, my plans are to pursue this patch set further. Unfortunately I am waiting for action out of the FSF copyright clerk so that I can update my employer disclaimer.

The patch is not forgotten. Previously I was working on it to make my own life a litter easier, but now I have an actual mandate to work on it.

David Daney


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