Implementation of debugger using INT 3

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
iman
Member
Member
Posts: 84
Joined: Wed Feb 06, 2019 10:41 am
Libera.chat IRC: ImAn

Implementation of debugger using INT 3

Post by iman »

Dear.
I would like to have a minimal debugger implemented as the software-generated breakpoint for my OS.
What I try to implement is a function to generate a breakpoint and look at some variables in my C code.
for instance:

Code: Select all

void do_something(void)
{
    int n = 0;
    n += 10;
    // here comes the function call to generate the breakpoint to look at the value of the variable n
    [...]
}
What I have read is that I should know exactly in which memory address, I have to put the INT 3.
The question is that which strategies should I follow for this reason?
Is it good to have the address of variable n (i.e. int* m = &n;) and set the INT 3 at that particular address?
In the end I need it for variables changing in a large loop. Perhaps simply using printf would not be a good way.

Best regards.
Iman.
Iman Abdollahzadeh
Github
Codeberg
User avatar
iansjack
Member
Member
Posts: 4705
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Implementation of debugger using INT 3

Post by iansjack »

You need to put the int 3 instruction at the point in your code where you want it to break. You can't use the address of a variable for this.

If you are running in a virtual machine (highly recommended whilst developing your OS) use a good debugger, such as gdb, rather than trying to reinvent the wheel.
nullplan
Member
Member
Posts: 1796
Joined: Wed Aug 30, 2017 8:24 am

Re: Implementation of debugger using INT 3

Post by nullplan »

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).
Carpe diem!
Post Reply