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

[malc]

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.

> 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:address@hidden