From: "Abid, Hafiz" <hafiz_abid@mentor.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: gdb@sourceware.org, riku.voipio@iki.fi, macro@codesourcery.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] GDB function call failing due to memory protection of stack page in QEMU
Date: Thu, 18 Apr 2013 10:28:13 +0100 [thread overview]
Message-ID: <1366277293.30939.3@abidh-ubunto1104> (raw)
In-Reply-To: <CAFEAcA_1_+xnCU-s4CSbMJbk-CSAy9mL2YThNo9-tXUOT_C9eg@mail.gmail.com> (from peter.maydell@linaro.org on Thu Apr 18 09:36:55 2013)
On 18/04/13 09:36:55, Peter Maydell wrote:
> > There are 2 possible solution in my mind. One was to allow writing
> memory if
> > this page originally had write access. This is a single line fix
> and a patch
> > is below.
>
> My worry here is that this will mean that writes by the
> debugger won't trigger the "code area has been written, QEMU
> must throw away any cached translated code for that region"
> check. This is a tricky area of the code...
Thanks for your comments. I have observed that in this case, code does
end up calling
tb_invalidate_phys_page() which should invalidate the translated code.
Please see the call
stack below.
Also the comments in the page_unprotect() and page_check_range() seem
to suggest that code
was written with similar case in mind.
page_check_range()
/* unprotect the page if it was put read-only because it
contains translated code */
if (!(p->flags & PAGE_WRITE)) {
if (!page_unprotect(addr, 0, NULL)) {
return -1;
}
page_unprotect()
/* if the page was really writable, then we change its
protection back to writable */
if ((p->flags & PAGE_WRITE_ORG) && !(p->flags & PAGE_WRITE)) {
Having said that, I am open to other ideas to solve this problem. The
2nd idea I have was to not add
write protection to a page if it meets certain condition as I described
in my original email. Does that look
like a better solution to you?
tb_invalidate_phys_page() at translate-all.c:1,157 0x800d1321
page_unprotect() at translate-all.c:1,811 0x800d1f8c
page_check_range() at translate-all.c:1,768 0x800d20a9
access_ok() at qemu.h:286 0x8002ab7c
lock_user() at qemu.h:397 0x8002ab7c
cpu_memory_rw_debug() at exec.c:1,851 0x8002ab7c
target_memory_rw_debug() at gdbstub.c:49 0x8004610a
gdb_handle_packet() at gdbstub.c:2,273 0x8004610a
gdb_read_byte() at gdbstub.c:2,728 0x80046ef5
page_unprotect() at translate-all.c:1,811 0x800d1f87
page_check_range() at translate-all.c:1,768 0x800d20a9
access_ok() at qemu.h:286 0x8002ab7c
lock_user() at qemu.h:397 0x8002ab7c
cpu_memory_rw_debug() at exec.c:1,851 0x8002ab7c
target_memory_rw_debug() at gdbstub.c:49 0x8004610a
gdb_handle_packet() at gdbstub.c:2,273 0x8004610a
gdb_read_byte() at gdbstub.c:2,728 0x80046ef5
gdb_handlesig() at gdbstub.c:2,812 0x80046ef5
Regards,
Abid
>
> thanks
> -- PMM
>
prev parent reply other threads:[~2013-04-18 9:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 11:20 [Qemu-devel] GDB function call failing due to memory protection of stack page in QEMU Abid, Hafiz
2013-04-18 8:31 ` Abid, Hafiz
2013-04-18 8:36 ` Peter Maydell
2013-04-18 9:28 ` Abid, Hafiz [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=1366277293.30939.3@abidh-ubunto1104 \
--to=hafiz_abid@mentor.com \
--cc=gdb@sourceware.org \
--cc=macro@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/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).