From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58771 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOohS-0005Nq-Vx for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:14:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOohR-0003a4-Nj for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:14:22 -0400 Received: from fe02x03-cgp.akado.ru ([77.232.31.165]:61810 helo=akado.ru) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOohR-0003Zu-Fw for qemu-devel@nongnu.org; Wed, 16 Jun 2010 05:14:21 -0400 Date: Wed, 16 Jun 2010 13:14:18 +0400 (MSD) From: malc Subject: Re: [Qemu-devel] Re: [Bug 581353] Re: qemu doesn't stop execution upon hitting a breakpoint In-Reply-To: <4C18852C.5010209@web.de> Message-ID: References: <20100516152304.10489.35592.malonedeb@potassium.ubuntu.com> <20100616070748.20899.45040.malone@wampee.canonical.com> <4C187FD7.5080601@web.de> <4C188203.5060402@web.de> <4C18852C.5010209@web.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: chimeranet89@gmail.com, qemu-devel@nongnu.org, Jun Koi On Wed, 16 Jun 2010, Jan Kiszka wrote: > Jun Koi wrote: > > On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka wrote: > >> Jun Koi wrote: > >>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka wrote: > >>>> Jun Koi wrote: > >>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo wrote: > >>>>>> Same thing happens to me, same versions as above.. I must turn to > >>>>>> another app to accomplish my work while awaiting for a bug-fix, the code > >>>>>> is perfectly executed but while gdb hits the breakpoints qemu goes on.. > >>>>>> > >>>>>> -- > >>>>>> qemu doesn't stop execution upon hitting a breakpoint > >>>>>> https://bugs.launchpad.net/bugs/581353 > >>>>>> You received this bug notification because you are a member of qemu- > >>>>>> devel-ml, which is subscribed to QEMU. > >>>>> i think this bug has been fixed in 0.12.4. have you tried that?? > >>>> Or this is a well-known gdb deficit: if the bootloader operates in > >>>> real-mode, you have to set two breakpoints, one at the linear address to > >>>> make qemu catch it, and another one at the segment offset to avoid gdb > >>>> skipping the exit due to ip != bp-addr. > >>>> > >>>> gdb is still fairly restricted when it comes to system-level debugging, > >>>> specifically as it lacks support for special x86 registers and the > >>>> segmented addressing mode. > >>> what do you mean by "it lacks support for special x86 registers" ? > >> idtr, gdtr, ldtr, tr, crX - to name the most important ones. > > > > do you mean gdb has no command to show the values of these registers? > > or you mean it doenst have anyway to get notified when these registers > > are modified? (i dont see how this is useful for debugging, anway) > > Both: Neither supports gdb them as part of its register set nor does the > remote gdb protocol transport them. > > You need this for segmented addressing, either in real mode (linear > address = segment * 16 + offset) or in segmented protected mode (less Not true in general (big real mode), CPU still references hidden segment cache even when protection is enabled. > common in modern OSes, but at least still used for per-CPU variables in > Linux). And you need a way to detect the current operation mode at all > to switch between 16/32, and 64 bit registers (set arch i386 vs. > i386:x86-64). You don't need all this for application-level debugging, > and that's why gdb lacks it so far. > > Jan > > -- mailto:av1474@comtv.ru