“We didn't chase the fad of using every Intel CPU feature”

Post by burfog » Sun, May 13, 2018, 8:33 PM UTC

0x0 wrote: post #9

geofft wrote: post #4

This seems a bit too self-congratulatory to be technically meaningful. What feature did they not use? From the thread history, it sounds like they provided no way for a userspace debugger to (ask the kernel to) set a hardware breakpoint on a section of memory. That means that when you use gdb and set a single breakpoint on some instruction, gdb must instead fall back on single-stepping the entire program until it get…

I think the hardware breakpoint support is for breaking on memory accesses to a particular address. Setting a breakpoint on the execution of a particular opcode at a particular address is easier and can be done by just swapping in an "INT 3" instruction at the particular point with no overhead.

Post by tptacek » Sun, May 13, 2018, 11:31 PM UTC

geofft wrote: post #4

This seems a bit too self-congratulatory to be technically meaningful. What feature did they not use? From the thread history, it sounds like they provided no way for a userspace debugger to (ask the kernel to) set a hardware breakpoint on a section of memory. That means that when you use gdb and set a single breakpoint on some instruction, gdb must instead fall back on single-stepping the entire program until it get…

Post by tptacek » Mon, May 14, 2018, 1:19 AM UTC

geofft wrote: post #34

tptacek wrote: post #33

Earlier quoted context omitted.

Am I misreading this or are you saying that without hardware breakpoints you have to single step all the way through the program to the breakpoint location? If so: that's a surprising and weird thing to say. Without hardware breakpoints, userspace debuggers work by overwriting the instruction at the target with an interrupting instruction, and then restoring it before resuming. I'm trying to imagine how gdb breakpoin…

Yes, you read what I said correctly, and I was wrong as others pointed out (I blame a lack of coffee).