2

I know that inserting a normal breakpoint can change the compiled code slightly, but is this also true for data breakpoints? I don't see how they could logically be put 'inline' with the code.

sji
  • 1,877
  • 1
  • 13
  • 28

2 Answers2

4

As far as i know break points are not changing the compiled code, neither normal ones or data breakpoints.

The program is being compiled using a compiler then the debugger runs using the compiled executable.

The code being changed is the in-memory code. The debugger loads the executable to the memory and change the code there.

user1708860
  • 1,683
  • 13
  • 32
  • A normal breakpoint will slightly change the compiled code, i think its just an INT3 instruction put before the line you put your breakpoint. See: http://stackoverflow.com/questions/3915511/how-do-breakpoints-work-in-c-code – sji Oct 01 '12 at 16:43
  • 2
    This person is correct. Proof: you can start an executable outside of the debugger, then attach a debugger to it and set a breakpoint. No change could possibly have happened to the compiled code. Edit: I see, thanks to your comment. I thought you were asking if the compiler generated different code if you had a breakpoint set, which it doesn't. But, you were asking if the debugger changed/instrumented the code in memory. – Tom W Oct 01 '12 at 16:44
  • A debugger will modify your code in memory, to insert an INT3 at the desired break-point. This is at runtime, nothing to do with compilation. – Mordachai Oct 01 '12 at 16:47
  • It changes a copy that is saved in the debugger's memory. What if the debugger crashes before it changed the code back? you will be stuck with a corrupted execution file. – user1708860 Oct 01 '12 at 16:47
  • 1
    The EXE image on disk is never modified. Just memory. – Mordachai Oct 01 '12 at 16:47
1

If you're referring to a "variable watch" or "memory break-point" where you're asking your debugger to break if a variable or region of memory changes, then that is accomplished by asking your CPU to monitor that memory address / range for all write access, and to break into the debugger to let it decide to break or not for each write. (I'm not privy to how the CPU/debugger exactly achieves this, just that it does).

This doesn't modify either the contents of your memory, or your executable code in memory.

Mordachai
  • 9,412
  • 6
  • 60
  • 112