From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21683 invoked by alias); 18 Apr 2013 09:28:23 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 21673 invoked by uid 89); 18 Apr 2013 09:28:22 -0000 X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 09:28:21 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1USl8c-0005kP-L7 from Hafiz_Abid@mentor.com ; Thu, 18 Apr 2013 02:28:18 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Apr 2013 02:28:18 -0700 Received: from abidh-ubunto1104 (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 18 Apr 2013 10:28:16 +0100 Date: Thu, 18 Apr 2013 09:28:00 -0000 From: "Abid, Hafiz" Subject: Re: [Qemu-devel] GDB function call failing due to memory protection of stack page in QEMU To: Peter Maydell CC: , , , In-Reply-To: (from peter.maydell@linaro.org on Thu Apr 18 09:36:55 2013) Message-ID: <1366277293.30939.3@abidh-ubunto1104> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-04/txt/msg00053.txt.bz2 On 18/04/13 09:36:55, Peter Maydell wrote: > > There are 2 possible solution in my mind. One was to allow writing=20=20 > memory if > > this page originally had write access. This is a single line fix=20=20 > and a patch > > is below. >=20 > 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=20=20 end up calling tb_invalidate_phys_page() which should invalidate the translated code.=20=20 Please see the call stack below. Also the comments in the page_unprotect() and page_check_range() seem=20=20 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=20=20 2nd idea I have was to not add write protection to a page if it meets certain condition as I described=20= =20 in my original email. Does that look like a better solution to you? tb_invalidate_phys_page() at translate-all.c:1,157 0x800d1321=09 page_unprotect() at translate-all.c:1,811 0x800d1f8c=09 page_check_range() at translate-all.c:1,768 0x800d20a9=09 access_ok() at qemu.h:286 0x8002ab7c=09 lock_user() at qemu.h:397 0x8002ab7c=09 cpu_memory_rw_debug() at exec.c:1,851 0x8002ab7c=09 target_memory_rw_debug() at gdbstub.c:49 0x8004610a=09 gdb_handle_packet() at gdbstub.c:2,273 0x8004610a=09 gdb_read_byte() at gdbstub.c:2,728 0x80046ef5=09 page_unprotect() at translate-all.c:1,811 0x800d1f87=09 page_check_range() at translate-all.c:1,768 0x800d20a9=09 access_ok() at qemu.h:286 0x8002ab7c=09 lock_user() at qemu.h:397 0x8002ab7c=09 cpu_memory_rw_debug() at exec.c:1,851 0x8002ab7c=09 target_memory_rw_debug() at gdbstub.c:49 0x8004610a=09 gdb_handle_packet() at gdbstub.c:2,273 0x8004610a=09 gdb_read_byte() at gdbstub.c:2,728 0x80046ef5=09 gdb_handlesig() at gdbstub.c:2,812 0x80046ef5 Regards, Abid >=20 > thanks > -- PMM >=20