Reputation: 13860
What kinds of bytes does GDB insert in memory to debug the executable?
I know that GDB must insert (or manipulate) some bytes in memory, since when I debug a program that computes, i.e., the XOR over a region of memory and set the breakpoint within this region, then the program computes the wrong result.
However, if I do x
(inspect memory), then everything in memory seems unchanged.
My question is therefore:
Suppose I set a breakpoint, e.g., b *0x40206e
. What (invisble) changes does GDB make to the executable within memory to support debugging it?
Upvotes: 2
Views: 682
Reputation: 213586
I know that GDB must insert (or manipulate) some bytes in memory t You know that it does, not that it must.
GDB could instead use debug registers to insert (small number of) breakpoints without modifying program code, but it's easier to simply insert 0xCC
at every breakpoint address: doing so doesn't have any limitations, works on all processors, and is simply easier.
Thus, to insert a breakpoint on x86, GDB saves the first byte of the original instruction in its own memory (so it can restore the original instruction later), and overwrites that byte with 0xCC
(the int3
"trap to debugger" instruction).
However, if I do x (inspect memory), then everything in memory seems unchanged.
That's because GDB knows where it has inserted breakpoints, and pretends that the program code is unmodified (in other words, the examine
command shows you what is supposed to be in memory, not what actually is there).
If it didn't, it would be very confusing to e.g. issue disassemble
command and see int3
and "gargbage" remains of the original instructions.
Upvotes: 1