4 ms·

One thing that really confuses me about how breakpoints function is that, for example, they mention a single instruction step mode. Wouldn't that halt the proce

One thing that really confuses me about how breakpoints function is that, for example, they mention a single instruction step mode. Wouldn't that halt the processor completely once it has stepped? I imagine the OS wouldn't exactly be happy about that. Is that sort of thing handled in the OS, so it allows it to run for a single step before moving to the next process, or is it more of a hardware thing where that process is running on a single block (core?) inside the CPU, and that block can be "paused", while the rest of the CPU carries on? And could similar debugging systems have worked on processors like a 6502, where it's just a single thread of execution?

pm215 2y ago
Generally speaking, hardware single-step is done by the OS telling the CPU "when you next execute an instruction in usermode, immediately afterwards take an exception and give me back control". (The details are more fiddly and the hardware might also let you do weirder things, but that's the right starting mental model to have of it, I think.) So when the debugger asks the OS "please single step this other process", the OS arranges to set the "do a single step" flag before returning to that other process; then when the exception happens and the OS gets back control after the single step it can tell the debugger "the single step has completed".
- voidUpdate 2y ago
  Ah, ok, so it's like it automatically inserts an int3 after the next step when you tell it to single step, and then the process is frozen again by that inserted int3 until the OS lets it go again? (Probably not actually inserting int3 but you get my example)
  - pm215 2y ago
    Yeah, it doesn't actually insert a breakpoint, because then you need to look at the instruction to see what all the places it could end up next are (eg if it's a conditional branch you need a bp on both fall-through and take-branch). The "pure software" singlestep pjc50 mentions works like that, where it really is the debugger process looking at the instruction being single-stepped and manually inserting breakpoints the same way it would for any other kind of breakpoint it wanted (which is potentially pretty annoying to do for things like computed branches). But hardware-assisted singlestep doesn't need to do that, because the CPU can know when it's completed execution of the instruction and trigger the exception back to the OS right then. (NB: I'm most familiar with Arm CPU singlestep; I don't know exactly what Intel CPUs provide for this.)
    - voidUpdate 2y ago
      Alright, thanks so much =) I'm learning things today haha
pjc50 2y ago
There are two possible debug modes: "software", which is what people are normally used to in Visual Studio etc, and "hardware", which involves connecting an in-circuit debugger to a CPU from the outside (usually over JTAG, or ARM SWD single-wire-debug). Hardware mode does indeed halt the processor completely when you hit a breakpoint. You can then inspect its state from outside. You can do this kind of breakpoint inside a hardware interrupt service routine if you need to. The software on the target is completely undisturbed, except for the amount of time taken. This is routine in microcontroller development. It's more work to do JTAG debugging on a modern Intel CPU but it's also possible: https://www.asset-intertech.com/resources/blog/2016/07/the-three-types-of-jtag-access-on-intel-based-designs/ https://www.asset-intertech.com/resources/blog/2016/07/the-t... (not 100% sure how halted you can get an Intel CPU in this kind of state, but for OS debugging the answer is probably pretty comprehensively halted on all units) Software mode implements single step by simply placing a temporary breakpoint on the next instruction. Return control to target process, run the instruction, breakpoint transfers control back to OS, debug process moves the breakpoint to the next instruction, and so on. You can have a software debugger even on very old systems. They used to be called "monitors". https://en.wikipedia.org/wiki/Resident_monitor https://en.wikipedia.org/wiki/Resident_monitor , as in the M of "CP/M".
- voidUpdate 2y ago
  Right, so I'm vaguely familiar with the "hardware" style, and I think that's what was confusing me since the computer itself keeps running, but that single process stops, which didn't jive with what I knew about debugging. Thank you =) And yes, now that you mention "monitors", I think I remember seeing some for the C64 and such like in the past

pm215 2y ago

Generally speaking, hardware single-step is done by the OS telling the CPU "when you next execute an instruction in usermode, immediately afterwards take an exception and give me back control". (The details are more fiddly and the hardware might also let you do weirder things, but that's the right starting mental model to have of it, I think.) So when the debugger asks the OS "please single step this other process", the OS arranges to set the "do a single step" flag before returning to that other process; then when the exception happens and the OS gets back control after the single step it can tell the debugger "the single step has completed".

voidUpdate 2y ago
Ah, ok, so it's like it automatically inserts an int3 after the next step when you tell it to single step, and then the process is frozen again by that inserted int3 until the OS lets it go again? (Probably not actually inserting int3 but you get my example)
- pm215 2y ago
  Yeah, it doesn't actually insert a breakpoint, because then you need to look at the instruction to see what all the places it could end up next are (eg if it's a conditional branch you need a bp on both fall-through and take-branch). The "pure software" singlestep pjc50 mentions works like that, where it really is the debugger process looking at the instruction being single-stepped and manually inserting breakpoints the same way it would for any other kind of breakpoint it wanted (which is potentially pretty annoying to do for things like computed branches). But hardware-assisted singlestep doesn't need to do that, because the CPU can know when it's completed execution of the instruction and trigger the exception back to the OS right then. (NB: I'm most familiar with Arm CPU singlestep; I don't know exactly what Intel CPUs provide for this.)
  - voidUpdate 2y ago
    Alright, thanks so much =) I'm learning things today haha

pjc50 2y ago

There are two possible debug modes: "software", which is what people are normally used to in Visual Studio etc, and "hardware", which involves connecting an in-circuit debugger to a CPU from the outside (usually over JTAG, or ARM SWD single-wire-debug). Hardware mode does indeed halt the processor completely when you hit a breakpoint. You can then inspect its state from outside. You can do this kind of breakpoint inside a hardware interrupt service routine if you need to. The software on the target is completely undisturbed, except for the amount of time taken. This is routine in microcontroller development. It's more work to do JTAG debugging on a modern Intel CPU but it's also possible: https://www.asset-intertech.com/resources/blog/2016/07/the-three-types-of-jtag-access-on-intel-based-designs/ https://www.asset-intertech.com/resources/blog/2016/07/the-t... (not 100% sure how halted you can get an Intel CPU in this kind of state, but for OS debugging the answer is probably pretty comprehensively halted on all units) Software mode implements single step by simply placing a temporary breakpoint on the next instruction. Return control to target process, run the instruction, breakpoint transfers control back to OS, debug process moves the breakpoint to the next instruction, and so on. You can have a software debugger even on very old systems. They used to be called "monitors". https://en.wikipedia.org/wiki/Resident_monitor https://en.wikipedia.org/wiki/Resident_monitor , as in the M of "CP/M".

voidUpdate 2y ago
Right, so I'm vaguely familiar with the "hardware" style, and I think that's what was confusing me since the computer itself keeps running, but that single process stops, which didn't jive with what I knew about debugging. Thank you =) And yes, now that you mention "monitors", I think I remember seeing some for the C64 and such like in the past