From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <palves@redhat.com>
Cc: tromey@sourceware.org, gdb-patches@sourceware.org,
"Tom Tromey \(Code Review\)"
<gerrit@gnutoolchain-gerrit.osci.io>
Subject: Re: [review] Handle pending stops from the Windows kernel
Date: Tue, 19 Nov 2019 14:20:00 -0000 [thread overview]
Message-ID: <87eey4x80s.fsf@tromey.com> (raw)
In-Reply-To: <94963d2c-961d-e48b-4e24-ad69472114d6@redhat.com> (Pedro Alves's message of "Thu, 14 Nov 2019 20:27:32 +0000")
>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
>> + else if (desired_stop_thread_id != -1 && desired_stop_thread_id != thread_id)
>> + {
>> + /* Pending stop. See the comment by the definition of
>> + "pending_stops" for details on why this is needed. */
>> + DEBUG_EVENTS (("get_windows_debug_event - "
>> + "unexpected stop in 0x%x (expecting 0x%x)\n",
>> + thread_id, desired_stop_thread_id));
>> +
>> + pending_stops.push_back ({thread_id, *ourstatus, current_event});
Pedro> I think you should unwind the PC here, not only when returning the pending
Pedro> event to GDB core. Consider the case of two threads hitting a breakpoint
Pedro> at the same time. When that happens, and do you "info threads", you want to
Pedro> see the PC of all threads pointing at a valid instruction. If you don't
Pedro> unwind the PC of pending breakpoints, then the threads with pending breakpoints
Pedro> will have their PC offset by one.
I think I tried this, but I can try again.
>> + if (software_breakpoint_inserted_here_p (regcache->aspace (), pc))
Pedro> Why is software_breakpoint_inserted_here_p needed?
Offsetting the PC did not work without this.
I tried to document my findings here:
https://sourceware.org/ml/gdb-patches/2019-10/msg00338.html
IIRC what happened is that gdb would sometimes resume the inferior with
wrong PC, causing it to crash. However, I don't really recall, since it
was a long time ago now. I guess I'll re-do the experiments.
Tom
next prev parent reply other threads:[~2019-11-19 14:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 18:05 Tom Tromey (Code Review)
2019-11-04 14:40 ` Luis Machado (Code Review)
2019-11-14 20:27 ` Pedro Alves
2019-11-19 14:20 ` Tom Tromey [this message]
2019-11-19 17:22 ` Pedro Alves
2019-11-26 17:08 ` Tom Tromey
2019-11-19 1:01 ` Joel Brobecker (Code Review)
2019-11-26 17:16 ` [review v2] " Tom Tromey (Code Review)
2019-11-29 19:08 ` Pedro Alves (Code Review)
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=87eey4x80s.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=gerrit@gnutoolchain-gerrit.osci.io \
--cc=palves@redhat.com \
--cc=tromey@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).