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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

Jun Koi wrote:
> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Jun Koi]

On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Jun Koi wrote:
>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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" ?

thanks,
J

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

Jun Koi wrote:
> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Jun Koi wrote:
>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Jun Koi]

On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> Jun Koi wrote:
>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>> Jun Koi wrote:
>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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)

thanks,
J

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

[Please keep the list in CC]

chimeranet89@gmail.com wrote:
> I never thought about this, since I always used qemu + gdb without
> having this kind of trouble.. I just finished compiling version 0.12.4,
> and I will surely try what you are suggesting, I really appreciate your
> help.

The restriction doesn't bite you that hard when in flat mode, the mode
modern OSes run in most of the time. And you can manually work around it
to some degree by letting qemu dump the registers ("monitor info
registers") and doing some manual calculation, e.g. for offset-based
gs/fs addressing (per-CPU variable under Linux).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]

Jun Koi wrote:
> On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Jun Koi wrote:
>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> Jun Koi wrote:
>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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
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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[chimeranet89]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

Ok this is it:

I've just compiled and tried qemu 0.12.4, this bug has been fixed and it  
works perfectly again, I'm adding a report to launchpad within the next few  
seconds.. Thank you for the support.

[-- Attachment #2: Type: text/html, Size: 219 bytes --]

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 <jan.kiszka@web.de> wrote:
> >> Jun Koi wrote:
> >>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>> Jun Koi wrote:
> >>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

malc wrote:
> On Wed, 16 Jun 2010, Jan Kiszka wrote:
> 
>> Jun Koi wrote:
>>> On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>> Jun Koi wrote:
>>>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>>>>>> Jun Koi wrote:
>>>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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...

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
>>
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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:

> malc wrote:
> > On Wed, 16 Jun 2010, Jan Kiszka wrote:
> > 
> >> Jun Koi wrote:
> >>> On Wed, Jun 16, 2010 at 4:49 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>> Jun Koi wrote:
> >>>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>>> Jun Koi wrote:
> >>>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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.
                                  ^^^^^^^ disabled 

> Unfortunately, the BIOS does not start in big real mode e.g...

It's actually fortunate since there's no access whatsoever to the cache
(on a real system that is)

-- 
mailto:av1474@comtv.ru

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

[malc]

On Wed, 16 Jun 2010, malc wrote:

> On Wed, 16 Jun 2010, Jan Kiszka wrote:
> 
> > malc wrote:
> > > On Wed, 16 Jun 2010, Jan Kiszka wrote:

[..snip..]

> > >>
> > >> 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.
>                                   ^^^^^^^ disabled
                                    ^^^^^^^ enabled

I need to get some proper sleep one of these days.. Sorry for the noise.

> > Unfortunately, the BIOS does not start in big real mode e.g...
> 
> It's actually fortunate since there's no access whatsoever to the cache
> (on a real system that is)
> 
> 

-- 
mailto:av1474@comtv.ru

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 <jan.kiszka@web.de> wrote:
> >>>> Jun Koi wrote:
> >>>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
> >>>>>> Jun Koi wrote:
> >>>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimeranet89@gmail.com> 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.