Fast breakpoints: design and implementation

Fast breakpoints: design and implementation
复制标题

快速断点:设计与实现

DOI:
10.1145/93542.93555
复制
发表时间:
1990
期刊:
Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2
影响因子:
--
通讯作者:
P. Kessler
P. Kessler
中科院分区:
--
文献类型:
--
作者:
P. Kessler

文献摘要

被引文献

相似文献

我们已经设计并实现了一个快速断点设施。断点通常被认为是交互式调试器的一个功能,在这种情况下,断点不需要特别快。在我们的环境中,断点通常用于非交互式信息收集;例如,过程调用计数和语句执行计数分析[Swinehart等人]。当非交互式使用时,断点应该尽可能快,以便尽可能少地干扰程序的执行。即使在交互式调试器中,条件断点设施也会受益于断点,这些断点可以快速地转移到条件的评估,并且如果条件不满足,则可以迅速地继续。这样的条件断点可以用来检查断言等。程序建议也可以使用快速断点[Teitelman]。建议的示例包括跟踪、计时甚至动画,所有这些都应该成为高级编程环境的一部分。 我们已经将Cedar环境从支持断点微码的机器[Lampson和Pier]移植到运行C代码的商业平台[Atkinson等人]。我们的大多数端口都在Unix* 操作系统下运行,因此为Cedar实现断点的一个选择是使用该系统提供的断点工具。Unix操作系统提供的断点对于我们所考虑的应用程序来说太慢了几个数量级(并且还有几个进程切换太复杂)。因此,我们设计了一个断点系统,对于我们的目的来说足够快。 单处理器的断点运行单线程的控制曾经是快速和简单的实现。本文表明,即使在多处理器上有多个控制线程,断点仍然可以很快。本文介绍了在现代计算机体系结构和编程风格的断点包的设计问题,以及我们的解决方案,他们为特定的体系结构。
We have designed and implemented a fast breakpoint facility. Breakpoints are usually thought of as a feature of an interactive debugger, in which case the breakpoints need not be particularly fast. In our environment breakpoints are often used for non-interactive information gathering; for example, procedure call count and statement execution count profiling [Swinehart, et al.]. When used non-interactively, breakpoints should be as fast as possible, so as to perturb the execution of the program as little as possible. Even in interactive debuggers, a conditional breakpoint facility would benefit from breakpoints that could transfer to the evaluation of the condition rapidly, and continue expeditiously if the condition were not satisfied. Such conditional breakpoints could be used to check assertions, etc. Program advising could also make use of fast breakpoints [Teitelman]. Examples of advising include tracing, timing, and even animation, all of which should be part of an advanced programming environment. We have ported the Cedar environment from a machine with microcode support for breakpoints [Lampson and Pier] to commercial platforms running C code [Atkinson, et al.]. Most of our ports run under the Unix* operating system, so one choice for implementing breakpoints for Cedar was to use the breakpoint facility provided by that system. The breakpoints provided by the Unix operating system are several orders of magnitude too slow (and also several process switches too complicated) for the applications we have in mind. So we designed a breakpoint system that was fast enough for our purposes. Breakpoints for uni-processors running single threads of control used to be fast and simple to implement. This paper shows that breakpoints can still be fast, even with multiple threads of control on multi-processors. This paper describes problems in the design of a breakpoint package for modern computer architectures and programming styles, and our solutions to them for a particular architecture.