From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ept3z-00082T-95 for qemu-devel@nongnu.org; Fri, 23 Dec 2005 14:58:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ept3y-00082E-OL for qemu-devel@nongnu.org; Fri, 23 Dec 2005 14:58:51 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ept3y-00082A-Lm for qemu-devel@nongnu.org; Fri, 23 Dec 2005 14:58:50 -0500 Received: from [64.233.162.194] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ept3K-0006Q1-3H for qemu-devel@nongnu.org; Fri, 23 Dec 2005 14:58:10 -0500 Received: by zproxy.gmail.com with SMTP id r28so84797nza for ; Fri, 23 Dec 2005 11:57:43 -0800 (PST) Message-ID: <16af12af0512231157n4efb01eemd4afbca65dea9d4@mail.gmail.com> Date: Fri, 23 Dec 2005 11:57:42 -0800 From: Andre Pech MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14949_14384561.1135367862987" Subject: [Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_14949_14384561.1135367862987 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I had been running into problems using gdb to debug the virtual machine kernel. The problem I was experiencing is that I would set a breakpoint, bu= t that gdb would only sometimes get notified that the breakpoint was hit. I finally tracked down the problem to exec.c:breakpoint_invalidate. The problem is that breakpoint_invalidate, which is supposed to invalidate the translation block for the address you want to break at, was actualling invalidating the translation block for the base address of the page that contained your breakpoint address. The fix is actually very simple and is attached below. Thanks Andre Pech diff -dc exec.c{.old,} *** exec.c.old 2005-12-23 11:40:47.000000000 -0800 --- exec.c 2005-12-23 11:41:13.000000000 -0800 *************** *** 996,1001 **** --- 996,1002 ---- target_ulong phys_addr; phys_addr =3D cpu_get_phys_page_debug(env, pc); + phys_addr +=3D pc & (~TARGET_PAGE_MASK); tb_invalidate_phys_page_range(phys_addr, phys_addr + 1, 0); } #endif On 12/21/05, Mulyadi Santosa wrote: > > Hello Andre... > > > I'm running into problems using qemu to debug a kernel module. My > > host and virtual machine are both x86 running Fedora Core 4. After > > insmoding the module in the virtual machine, starting gdbserver, > > running gdb on the host with the module sections loaded at the right > > place, and setting a breakpoint in the module code, gdb does not > > always get notified when the code is exectuted. After adding > > I'm not doing module debugging, only core kernel code debugging, but > more or less I run into same situation (last time confirmed with Qemu > 0.7.1) > > For additional info, sometimes I also suffered the other condition. > Breakpoint is hit, but even if I delete it, the emulation still stops > whenever the code at related physical address is hit. I tried to > printf() every gdb command received by Qemu's gdbstub and it confirmed > that breakpoint deletion command is actually received, but I can't > confirm what is the real bug there. > > regards > > Mulyadi > > ------=_Part_14949_14384561.1135367862987 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,
I had been running into problems using gdb to debug the virtual machine kernel. The problem I was experiencing is that I would set a breakpoint, but that gdb would only sometimes get notified that the breakpoint was hit.
I finally tracked down the problem to exec.c:breakpoint_invalidate. The problem is that breakpoint_invalidate, which is supposed to invalidate the translation block for the address you want to break at, was actualling invalidating the translation block for the base address of the page that contained your breakpoint address. The fix is actually very simple and is attached below.
Thanks
Andre Pech


diff -dc exec.c{.old,}
*** exec.c.old    2005-12-23 11:40:47.000000000 -0800
--- exec.c    2005-12-23 11:41:13.000000000 -0800
***************
*** 996,1001 ****
--- 996,1002 ----
      target_ulong phys_addr;
 
      phys_addr =3D cpu_get_phys_page_debug(env, p= c);
+     phys_addr +=3D pc & (~TARGET_PAGE_MASK);
      tb_invalidate_phys_page_range(phys_addr, phy= s_addr + 1, 0);
  }
  #endif


On 12/21/05, Mulyadi Santosa <a_mu= lyadi@softhome.net > wrote:
Hello Andre...

> I'm running into problems using qemu to debug a = kernel module. My
> host and virtual machine are both x86 running Fed= ora Core 4. After
> insmoding the module in the virtual machine, star= ting gdbserver,
> running gdb on the host with the module sections loaded at the rig= ht
> place, and setting a breakpoint in the module code, gdb does not=
> always get notified when the code is exectuted. After adding

I'm not doing module debugging, only core kernel code debugging, butmore or less I run into same situation (last time confirmed with Qemu
0= .7.1)

For additional info, sometimes I also suffered the other condi= tion.
Breakpoint is hit, but even if I delete it, the emulation still stopswhenever the code at related physical address is hit. I tried to
print= f() every gdb command received by Qemu's gdbstub and it confirmed
that b= reakpoint deletion command is actually received, but I can't
confirm what is the real bug there.

regards

Mulyadi

------=_Part_14949_14384561.1135367862987--