From: "Philippe Mathieu-Daudé" <1792659@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1792659] Re: watchpoints might not properly stop execution at the right address
Date: Sun, 09 May 2021 16:17:52 -0000 [thread overview]
Message-ID: <162057707262.16458.12842706985808598077.malone@soybean.canonical.com> (raw)
In-Reply-To: 153697392900.9226.4246206563741650584.malonedeb@soybean.canonical.com
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/245
** Changed in: qemu
Status: Confirmed => Invalid
** Changed in: qemu
Assignee: Richard Henderson (rth) => (unassigned)
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #245
https://gitlab.com/qemu-project/qemu/-/issues/245
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1792659
Title:
watchpoints might not properly stop execution at the right address
Status in QEMU:
Invalid
Bug description:
This bug has been tested with the latest development tree
(19b599f7664b2ebfd0f405fb79c14dd241557452).
I am using qemu-system-i386 with the gdbserver stub. I set a
watchpoint on some address. When the watchpoint is hit, it will be
reported by gdb, but it might happen that eip points to the wrong
address (execution has not properly stopped when the watchpoint was
hit).
The setup I used to reproduce it is quite complex, but I believe I
have found the cause of the bug, so I will describe that.
The check_watchpoint() function sets cflags_next_tb in order to force
the execution of only one instruction, and then exits the current tb.
It then expects to be called again after that one instruction is
executed, the watchpoint is hit and it is reported to gdb.
The problem is that another interrupt might have been generated around
the same time as the watchpoint. If the interrupt changes eip and
execution goes on in another address, the value of cflags_next_tb will
be spoiled. When we come back from the interrupt to the address where
the watchpoint is hit, it is possible that a tb with multiple
instructions is been executed, and therefore eip points to the wrong
address, ahead of where it should be.
In my case, the order is as follows:
* i8259 generates an IRQ
- cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and CPU_INTERRUPT_HARD
* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called
- it deals with CPU_INTERRUPT_TGT_EXT_1
- execution continues
* I am exactly at the instruction where the watchpoint is hit.
- check_watchpoint() is called and cflags_next_tb is set to force the execution of only one instruction.
- execution breaks out of the loop with siglongjmp()
* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called
- it deals with the IRQ. eip is changed and cflags_next_tb is spoiled
- execution continues at the IRQ
[...]
* The kernel finishes dealing with the IRQ
* I am back at the instruction where the watchpoint is hit.
- A tb is created and executed with two instructions instead of one
- eip is now ahead of the instruction that hit the watchpoint
* cpu_handle_interrupt() is called
- it deals with CPU_INTERRUPT_DEBUG
- the watchpoint is reported by gdb, but with the wrong eip.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1792659/+subscriptions
prev parent reply other threads:[~2021-05-09 16:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-15 1:12 [Qemu-devel] [Bug 1792659] [NEW] watchpoints might not properly stop execution at the right address Ramiro Polla
2020-11-12 18:26 ` [Bug 1792659] " Thomas Huth
2020-11-12 20:13 ` Alex Bennée
2020-11-12 20:29 ` Richard Henderson
2020-11-12 20:44 ` Richard Henderson
2021-05-09 16:17 ` Philippe Mathieu-Daudé [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=162057707262.16458.12842706985808598077.malone@soybean.canonical.com \
--to=1792659@bugs.launchpad.net \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).