If you want to write a debugger, you are going to have to parse the debug information present in the file. Debug information is really complicated. Believe me, the specifics of how breakpoints work are going to pale in comparison to that. For instance, you want to look at "n". Where is "n"? The debug information will tell you whether it is in a register or in memory, but sometimes the value will be only part of a combined expression saved somewhere. For instance:
Code: Select all
void *memset(void *pv, int x, size_t c) {
char *p = pv;
for (size_t i = 0; i < c; i++)
p[i] = x;
return pv;
}
It is highly likely that "p" will not be saved independent of "pv", and "i" will never be saved, but instead only "p + i". Which is a transformation the compiler can perform if it notices that it can decrement "c" for the loop counter. And now imagine the format of the structures that tell you that.
Breakpoints usually work this way: First the debugger determines the code address of the breakpoint target. Then it decides whether to use a hardware breakpoint or a software one. Hardware means it tells the OS to set the debug registers. Software means, the debugger saves the code at the target, then overwrites it with the breakpoint instruction. Then the target process is continued. When the BP hits, the target process is stopped and the debugger can examine the situation. If you want to continue from there, the BP is usually deactivated and the program is continued for a single step. Then, the breakpoint is reactivated.
Also, one detail: x86's breakpoint instruction is "int3" (CC), not "int 3" (CD 03).