Debugging
-
I`m trying to get a better understanding of how debugging works with programs build in an IDE. I have a guess on how it works but I`m hopping someone will confirm my guesses. So my guess is that the program your building it hooked through its update function (the function through which it gets updated by windows). When your run your program in debug mode the changes taking place inside your program are exchanged through the program update function as parameters with Windows which in its turn sends the data to the IDE.
-
I`m trying to get a better understanding of how debugging works with programs build in an IDE. I have a guess on how it works but I`m hopping someone will confirm my guesses. So my guess is that the program your building it hooked through its update function (the function through which it gets updated by windows). When your run your program in debug mode the changes taking place inside your program are exchanged through the program update function as parameters with Windows which in its turn sends the data to the IDE.
A Debug version of a program includes information that an external program (the debugger) can read, in order to identify which actual statement is being executed at any point in time. The debugger captures the execution at the beginning of the program or at any specified breakpoints, and can then execute or skip instructions as directed by the user. The debugger can be run from within the IDE, or stand-alone in a terminal window, depending on the system and framework in use. When run in the IDE it is just using the IDE Windows to display information.
-
A Debug version of a program includes information that an external program (the debugger) can read, in order to identify which actual statement is being executed at any point in time. The debugger captures the execution at the beginning of the program or at any specified breakpoints, and can then execute or skip instructions as directed by the user. The debugger can be run from within the IDE, or stand-alone in a terminal window, depending on the system and framework in use. When run in the IDE it is just using the IDE Windows to display information.
So basically the program being debugged is a sitting duck residing in the memory that an external program can read at will/without any formalities.
-
So basically the program being debugged is a sitting duck residing in the memory that an external program can read at will/without any formalities.
-
Not at all, since you, the user, are in control of the system and what application are running and what they are allowed to do. And Debug information is not a simple text file that anyone can immediately interpret.
thanks Richard
-
I`m trying to get a better understanding of how debugging works with programs build in an IDE. I have a guess on how it works but I`m hopping someone will confirm my guesses. So my guess is that the program your building it hooked through its update function (the function through which it gets updated by windows). When your run your program in debug mode the changes taking place inside your program are exchanged through the program update function as parameters with Windows which in its turn sends the data to the IDE.
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