The Computer Journal
Efficient debugging primitives for multiprocessors
ASPLOS III Proceedings of the third international conference on Architectural support for programming languages and operating systems
Experience with topaz telebugging
PADD '88 Proceedings of the 1988 ACM SIGPLAN and SIGOPS workshop on Parallel and distributed debugging
Fast breakpoints: design and implementation
PLDI '90 Proceedings of the ACM SIGPLAN 1990 conference on Programming language design and implementation
Design and validation of computer protocols
Design and validation of computer protocols
The flight recorder: an architectural aid for system monitoring
PADD '91 Proceedings of the 1991 ACM/ONR workshop on Parallel and distributed debugging
ASPLOS V Proceedings of the fifth international conference on Architectural support for programming languages and operating systems
Communicating sequential processes
Communications of the ACM
A Discipline of Programming
Adaptability and portability of symbolic debuggers
Adaptability and portability of symbolic debuggers
Specifying representations of machine instructions
ACM Transactions on Programming Languages and Systems (TOPLAS)
Pragmatic Aspects of Reusable Program Generators
SAIG '00 Proceedings of the International Workshop on Semantics, Applications, and Implementation of Program Generation
Pragmatic aspects of reusable program generators
Journal of Functional Programming
The New Jersey machine-code toolkit
TCON'95 Proceedings of the USENIX 1995 Technical Conference Proceedings
| Hi-index | 0.00 |
It is common for debuggers to implement breakpoints by a combination of planting traps and single stepping. When the target program contains multiple threads of execution, a debugger that is not carefully implemented may miss breakpoints. This paper gives a formal model of a breakpoint in a two-threaded program. The model describes correct and incorrect breakpoint implementations. Automatic search of the model's state space shows that the correct implementation does miss a breakpoint. The results apply even to debuggers like dbx and gdb, which are apparently for single-threaded programs; when the user evaluates an expression containing function calls, the debugger executes the call in the target address space, in effect creating a new thread.