Re: [Qemu-devel] Re: [Bug 581353] Re: qemu doesn't stop execution upon hitting a breakpoint

[Gleb Natapov]

On Wed, Jun 16, 2010 at 11:34:36AM +0200, Jan Kiszka wrote:
> malc wrote:
> > On Wed, 16 Jun 2010, Jan Kiszka wrote:
> > 
> >> Jun Koi wrote:
> >>> On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka <address@hidden> wrote:
> >>>> Jun Koi wrote:
> >>>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <address@hidden> wrote:
> >>>>>> Jun Koi wrote:
> >>>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <address@hidden> 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.
> 
> Unfortunately, the BIOS does not start in big real mode e.g...
> 
Actually x86 cpu starts in some strange mode (not exactly big real
mode). CS.base == 0xffff0000. That is why the first instruction bios
does is long jump to init CS.
 
> Jan
> 
> > 
> >> 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
> >>
> >>
> 
> 



--
                        Gleb.