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

[Jan Kiszka <jan.kiszka@web.de>]

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