From: David Daney <ddaney@caviumnetworks.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Pedro Alves <pedro@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [Patch] Use resume instead of target_resume when stepping over watchpoint.
Date: Fri, 31 Oct 2008 02:13:00 -0000 [thread overview]
Message-ID: <490A4FFD.2070806@caviumnetworks.com> (raw)
In-Reply-To: <20081030152933.GE13387@adacore.com>
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
prev parent reply other threads:[~2008-10-31 0:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 0:32 David Daney
2008-10-30 3:34 ` Joel Brobecker
2008-10-30 21:21 ` Pedro Alves
2008-10-30 21:43 ` Joel Brobecker
2008-10-31 2:13 ` David Daney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=490A4FFD.2070806@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox