![]() stepo : this is a kabalistic macro used to 'step-over' function and interrupt calls.For instance, you sometimes only wants to break when the function AH=0h of the interruption 10h is called (change screen mode). This is used to filter service calls of interrupts. AH has to be equals to the given parameter. break_int_if_ah : adds a conditional breakpoint on a software interrupt.break_int : adds a breakpoint on a software interrupt vector (the way the good old MS DOS and BIOS expose their APIs).You can then play with the classical nexti function that will step to the next instruction. The secret lies inside the stop-hook() function of the script: it will be executed each time gdb gets awaken. For instance, here you would have the very same display with cs = 0xF100 and ip = 0xD384. But if you are inspecting a code in memory, you cannot be sure of the offset part of the address. Suppose now that you want to add a breakpoint just after the return of the function, you will have to set a breakpoint at 0xe388 and not 0xfe388. you must know the content of cs when a code is executed before you can place a breakpoint.įor example, suppose the current values of cs and ip are respectively 0xF000 and 0圎384 and that you have asked the disassembling of cs * 16 + ip, gdb will display something like :.when you enable a breakpoint on an address x, your emulated code might break on every address s:x, where s is an arbitrary segment address.When you want to add a breakpoint at a given address inside the code, gdb (and the qemu/bochs remote server) will break when the value of eip reaches this particular address. The current instruction in real mode is located in memory at an address pointed to by cs:ip. However, in real mode, you also have to consider the code segment register cs. The result is very close to what the author displays in one of its post here (in french).įor gdb, the current instruction pointer is given by the register eip. That is what I did to feel more confortable with this old piece of code. That is why you always have to switch between these two representations of memory.įortunately, GDB can be scripted quite easily. For instance, it does not know anything about segmented memory access and only considers linear memory addresses. GDB and the gdb remote server implementations of Qemu (and bochs) has poor support for this mode. Each of them is 16 bits wide, and the resulting physical address is obtained by segment * 16 + offset. In this mode, every reference to a physical address in memory is made by the use of two pointers: a segment and an offset inside this segment. This a very annoying mode of the Intel processor, where registers and data are 16 bits wide and 20 bits (well. The problem is that we want to debug real mode code. ![]() (use the target remote localhost:1234 command inside gdb) In particular, it implements a gdb server, meaning a gdb client can connect to it and interact with the emulated CPU.įor that purpose, Qemu may be run with the following flags -S -s: it will freeze the cpu and wait for a gdb client to connect on localhost:1234. ![]() Special mode for GDBĪbout the debugging part, and because I run the program through QEmu, I had access to the debugging infrastructure offered by Qemu. Once located, the use of a disassembler becomes helpful. The first one allows to focus on a short portion of code where the problem might be located. I have been using two complementing approaches to find and fix the problem: debugging and disassembling. It has apparently been built with a DOS-based ancestor of Windev, called "Hyper Screen". The other difficulty was that I did not had access to the program's sources. But for various reasons, the program had to work with QEmu, I could not rely on dosbox. Other facts: it was exactly the same with bochs, but worked good with dosbox. The same program works perfectly well on a "physical" old machine. QEmu exhibited strange graphical behaviours with this particular application: only the upper half of the screen seemed to be correctly displayed, the other half left blank. Remote debugging of real mode code with gdbįor my work, I recently had to debug an old MS-DOS application that were running under QEmu.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |