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

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

[Alfredo Mungo]

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.

Status in QEMU: New

Bug description:
Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid.

I'm trying to debug some bootloader code. Using qemu -s -S to run the bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00. Then I type continue in gdb. The breakpoint is hit and gdb shows debug information. However qemu apparently continues to execute the code of the bootloader as the text is printed on the screen etc.

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

[Jun Koi]

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

J

[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: 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 --]

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.

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

[Alfredo Mungo]

Ok this issue has been fixed in qemu 0.12.4.

Just type 'qemu --version' to see what version you have, it is probably
outdated.

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

Status in QEMU: New

Bug description:
Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid.

I'm trying to debug some bootloader code. Using qemu -s -S to run the bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00. Then I type continue in gdb. The breakpoint is hit and gdb shows debug information. However qemu apparently continues to execute the code of the bootloader as the text is printed on the screen etc.

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

[T. Huth]

According to comment #3, this has been fixed, so let's change the bug
status accordingly.

** Changed in: qemu
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/581353

Title:
  qemu doesn't stop execution upon hitting a breakpoint

Status in QEMU:
  Fix Released

Bug description:
  Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid.

  I'm trying to debug some bootloader code. Using qemu -s -S to run the
  bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00.
  Then I type continue in gdb. The breakpoint is hit and gdb shows debug
  information. However qemu apparently continues to execute the code of
  the bootloader as the text is printed on the screen etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/581353/+subscriptions

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