Click here to Skip to main content
15,868,016 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
QuestionBest IDE for golang Pin
Gonzalo Cotanda Gisbert13-Dec-21 11:20
Gonzalo Cotanda Gisbert13-Dec-21 11:20 
AnswerRe: Best IDE for golang Pin
Richard MacCutchan13-Dec-21 21:56
mveRichard MacCutchan13-Dec-21 21:56 
QuestionDebugging Pin
Calin Negru13-Dec-21 1:12
Calin Negru13-Dec-21 1:12 
AnswerRe: Debugging Pin
Richard MacCutchan13-Dec-21 2:03
mveRichard MacCutchan13-Dec-21 2:03 
GeneralRe: Debugging Pin
Calin Negru13-Dec-21 3:58
Calin Negru13-Dec-21 3:58 
GeneralRe: Debugging Pin
Richard MacCutchan13-Dec-21 4:03
mveRichard MacCutchan13-Dec-21 4:03 
GeneralRe: Debugging Pin
Calin Negru13-Dec-21 5:54
Calin Negru13-Dec-21 5:54 
AnswerRe: Debugging (warning: Long answer - skip, rather than making tl;dr complaints!) Pin
kalberts13-Dec-21 18:09
kalberts13-Dec-21 18:09 
The really low level implementation may vary a lot.
A couple variants I have worked with:

To halt execution temporarily, e.g. an explicitly declared breakpoint, or implicit by e.g. a 'continue to next line', the debugger looks up the address of the first instruction generated for that source line in the debug information. It copies and saves the first instruction, and inserts a special breakpoint instruction. Most modern CPUs provide a specific instruction, generating an internal interrupt, causing exeution of an interrupt handler provided by the debugger. Also, most modern CPUs have a mechanism for executing a single instruction and then cause a similar internal interrupt. And, the handlers are run at a low priority so that a higher priority interrupt, e.g. the clock, may preempt the debugger interrupt handler to let other processes have their CPU share.

The debugger user dialog (e.g. to continue exectution, remove the breakpoint, display the current value of some variable etc.) takes place within this interrupt handler. When target execution is resumed, the debugger backs up the program counter to the start of the breakpoint instruction it has inserted, puts the saved "real" instruction into the code, sets the 'single instruction' flag to the CPU, and returns from the debug interrupt.

The single instruction interrupt reinserts the breakpoint instruction, ready for the next time execution passes through this point in code. It resets the single instruction flag and returns from interrupt, and target execution continues until the next breakpoint.

For 'run to next line', the debugger may find the first instruction of every relevant line in the code (usually limited to the current function and the continuation point upon return, but exception handlers may complicate this) and save all the instructions being overwritten. When any of the breakpoints are hit, the same restore-original / single step / reinsert breakpoint procedure is followed. The breakpoints remain until that scope is left, i.e. when the function is exited. The handler for that interrupt will restore all the original code, and then set breakpoints on all line starts in the new scope. Also if another function is called and another scope is entered, the debugger must set breakpoints in that scope.

In the old days when memory was scarce, setting a huge number of line start breakpoints and saving information for each of them would break all memory limits. So when halted at one line, as the single current breakpoint, the debugger would look up the start of every possible next line - one for linear execution, one for a line containing a function call, two for a conditional statement, ... Whichever of them were hit next, the debugger would restore the original code for them all, and repeat the search for possible next lines. This reduced debugger memory requirements a lot, but for every single line, the debugger had to do a possibly complex search for possible next lines.

Older machines might not provide a breakpoint instruction. I have seen it emulated by the OS - all machines have some internal interrupt mechanism for calling OS functions. So rather than a breakpoint instruction, the debugger inserts a breakpoint OS call. The OS will transfer control to the process that has registred itself as the debugger for the target process. On old machines with a small virtual adddress space, there might not be room for both the target and the debugger in one space, so to inspect current values in the target, the debugger might have to request the OS to provide it. So it must also ask the OS to please insert a breakpoint call in the target process at a specific address.

A small variation of that: One debugger injected a tiny routine - a few hundred bytes - in the target process. This routine could be contated over a TCP/IP connection from virtually anywhere, and could on request set and remove breakpoint instructions, return or set the current value of variable etc., at a purely binary level: The remote debugger provided absolute addresses for all operations by the routine. Since all symbol handling etc. was done at the remote debugger machine, the impact on the target system was almost zero both in CPU and memory consumption.

Inserting breakpoints (whether as instructions or as OS calls) is not possible in code in ROM, and in many cases not a viable solution if code is in flash memory. So some processors (typially targeted at embedded systems, where ROMmed/flashed code is common) provide a set of registers: Whenever the program counter is set to the value of one of these registers (with no modifications to program code), a debug interrupt is generated. The debugger need not restore any original instruction (or debug instruction after executing the original), but is limited to, say, four breakpoint locations active at the same time. For 'run to next line' operation, there is no alternative to search the debug information for possible next lines. If the number of possibilities is larger than debug registers available, it must resort to instruction-at-a-time exeution through the current line, an when the program counter goes out of the scope of the current line, use the debug information to see where it ended up, and give control to the debugger operator.

You may conclude that writing the core of a debugger is not a task you would give to a college freshnman. It really requires fingertip control over interrupts and addressing and instruction formats!
QuestionAddVectoredExceptionHandler in Release Pin
ForNow6-Dec-21 16:08
ForNow6-Dec-21 16:08 
AnswerRe: AddVectoredExceptionHandler in Release Pin
Richard MacCutchan6-Dec-21 21:23
mveRichard MacCutchan6-Dec-21 21:23 
GeneralRe: AddVectoredExceptionHandler in Release Pin
ForNow7-Dec-21 1:32
ForNow7-Dec-21 1:32 
GeneralRe: AddVectoredExceptionHandler in Release Pin
Richard MacCutchan7-Dec-21 1:35
mveRichard MacCutchan7-Dec-21 1:35 
GeneralRe: AddVectoredExceptionHandler in Release Pin
ForNow7-Dec-21 12:48
ForNow7-Dec-21 12:48 
GeneralRe: AddVectoredExceptionHandler in Release Pin
Richard MacCutchan7-Dec-21 22:03
mveRichard MacCutchan7-Dec-21 22:03 
QuestionErroneous information returned from CImage Class Pin
ForNow1-Dec-21 16:28
ForNow1-Dec-21 16:28 
AnswerRe: Erroneous information returned from CImage Class Pin
Victor Nijegorodov3-Dec-21 10:59
Victor Nijegorodov3-Dec-21 10:59 
QuestionRichard that worked better Please Read Pin
ForNow28-Nov-21 11:42
ForNow28-Nov-21 11:42 
AnswerRe: Richard that worked better Please Read Pin
Dave Kreskowiak28-Nov-21 18:46
mveDave Kreskowiak28-Nov-21 18:46 
QuestionCan GDI and RichEdit share the WindowClient (and live together) Pin
ForNow27-Nov-21 16:04
ForNow27-Nov-21 16:04 
AnswerRe: Can GDI and RichEdit share the WindowClient (and live together) Richard thanks for your help Pin
ForNow28-Nov-21 4:37
ForNow28-Nov-21 4:37 
GeneralRe: Can GDI and RichEdit share the WindowClient (and live together) Richard thanks for your help Pin
Richard MacCutchan28-Nov-21 5:21
mveRichard MacCutchan28-Nov-21 5:21 
GeneralRe: Can GDI and RichEdit share the WindowClient (and live together) Richard thanks for your help Pin
ForNow28-Nov-21 7:05
ForNow28-Nov-21 7:05 
GeneralRe: Can GDI and RichEdit share the WindowClient (and live together) Richard thanks for your help Pin
Richard MacCutchan28-Nov-21 8:11
mveRichard MacCutchan28-Nov-21 8:11 
GeneralRe: Can GDI and RichEdit share the WindowClient (and live together) Richard thanks for your help Pin
ForNow28-Nov-21 8:32
ForNow28-Nov-21 8:32 
AnswerCSpiltter has max row of 2 Pin
ForNow28-Nov-21 7:50
ForNow28-Nov-21 7:50 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.