There are a number of requirements for a break point
Logical vs Physical break points
Logical break points correspond to the ones set by the user somewhere in the source code. Physical break point correspond to the point in the text data area of a application where the physical trap instruction is written into.
A logical break point may be resolved (meaning it has a mapping from symbol to physical address), or it can be unresolved, where the required module has yet to be loaded (thus may not have address). Usually this means two lookup tables, the first maps logical bp to physical and is used when settings, removing a bp. The second is a backward lookup from physical to logical, used when triggering bp.
In general there is no restrictions on how many bps can point to the same physical address
Steps to creating a breakpoint
- Given filename and line number, look up symbol table to find physical address of the instruction
- Validate that the breakpoint can be set. The symbol may not yet be in memory because the library has not yet loaded, the symbol may not be valid due to old symbol files etc.
- Create logical and physical break point objects
- There can be temporary breakpoints that are used only once (for example stop at main() so we can begin running)
- Debugger may need to create internal breakpoints to service certain user requests. Internal bp should not be visible to users when viewing the CPU view (but a memory dump should review the breakpoint)
Steps to service a break point
- OS notifies debugger that the application has stopped at a certain address due to breakpoint
- Look up logical bp list to see if this is a breakpoint we have created
- Stop and get user input
- Note that step-over on the source level is not the same as step-over at instruction level. There could be manyof instructions for a single logic statement. The debugger should use internal bps at a source level to achieve step-over in source