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.kis...@web.de> wrote: >>>> Jun Koi wrote: >>>>> On Wed, Jun 16, 2010 at 4:40 PM, Jan Kiszka <jan.kis...@web.de> wrote: >>>>>> Jun Koi wrote: >>>>>>> On Wed, Jun 16, 2010 at 4:07 PM, Alfredo Mungo <chimerane...@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 >> >>
signature.asc
Description: OpenPGP digital signature
