调试器对并行程序干扰特性的研究

机群系统中并行程序的执行具有不确定性，这种不确定性给并行程序的调试带来了困难，并行程序的不确定性是由运行环境中的各种干扰因素造成的，该文研究交互式调试行为对调试程序的干扰特性，文中给出了算法可以在调试的过程中实时地报告出本次交互式调试操作是否对调试的程序造成了干扰。     

Dynamic Query-Based Debugging of Object-Oriented Programs

Program errors are hard to find because of the cause-effect gap between the instant when an error occurs and when the error becomes apparent to the programmer. Although debugging techniques such as conditional and data breakpoints help in finding errors in simple cases, they fail to effectively bridge the cause-effect gap in many situations. This paper proposes two debuggers that provide programmers with an instant error alert by continuously checking inter-object relationships while the debugged program is running. We call such tool a dynamic query-based debugger. To speed up dynamic query evaluation, our debugger implemented in portable Java uses a combination of program instrumentation, load-time code generation, query optimization, and incremental reevaluation. Experiments and a query cost model show that selection queries are efficient in most cases, while more costly join queries are practical when query evaluations are infrequent or query domains are small. To enable query-based debugging in the middle of program execution in a portable way, our debugger performs efficient Java class file instrumentation. We call such debugger an on-the-fly debugger. Though the on-the-fly debugger has a higher overhead than a dynamic query-based debugger, it offers additional interactive power and flexibility while maintaining complete portability.     

Improving the performance of reverse debugging

Reverse debugging is the software development technique that effectively helps fix bugs occurring at the nondeterministic program behavior. It allows one to examine the past states of the program without rerunning it. An implementation of reverse debugging based on deterministic replay in the QEMU 2.0 emulator is described. A number of techniques improving the debugging performance due to reducing the amount of saved data, optimized storage of system snapshots, indexing, and compressing of the event log are proposed. The emulator can work together with the interactive GDB debugger, which makes it possible to use the reverse-continue, reverse-nexti, reverse-stepi and reverse-finish commands in the course of debugging. The execution time of these commands depends on the frequency of recording the system’s state snapshots. An estimate of the optimal frequency for the reverse-continue command is obtained.     

开源跨平台的图像可视化调试器设计

目的 在调试C/C++图像处理程序时,如何以可视化的形式观察被调试程序中的图像变量,对于调试过程尤为关键。目前尚未有跨多操作系统平台的图像可视化调试器可供使用,该款开源跨平台的图像可视化调试器的设计与实现弥补了此领域的不足。方法 利用GDB(GNU debugger)调试器的Python接口,将被调试程序中的图像变量对应的内存字节序列转化成Python下的2维数组,并采用Matplotlib库加以显示,整个图像显示线程独立于GDB的文本字符交互主线程。结果 在Windows、Linux、Mac系统中分别进行实验,均可实现图像变量的显示、缩放、平移、像素数值查看、保存等多种功能,并使得GDB的命令行保持非阻塞模式运行。结论 开源跨平台的图像可视化调试器的设计,满足了不同操作系统平台下图像程序的开发调试需求,弥补了当前GDB调试图像程序功能的不足,提高了图像处理程序的开发和调试效率。     

远程调试的设计与实现

一般情况下,调试器与被调试程序（目标程序）运行在同一个计算机系统环境中,但是,在实时系统、内核调试及一些Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ系统等情况下,调试器不能运行在目标程序运行的环境中,此时有效的解决方法就是实施远程调试（Ｒｅｍｏｔｅ ｄｅｂｕｇｇｉｎｇ）。远程调试系统由本地调试器、远程调试服务器以及远程调试通讯协议组成。该文详细讨论这三部分的设计与实现,并介绍一个自行设计的基于远程调试的并行调试器。     

基于虚拟机日志记录回放的可逆调试方法

传统的调试器调试程序时,仅仅能够让程序正向运行并获取其当前的状态.提出了一种可以让程序逆向运行,回到过去任意时刻的调试方法,来增强调试器的功能.该方法是通过为Xen虚拟机添加完整的日志记录和回放功能以及对GDB调试器作相应修改来实现的;调试对象可以恢复到其运行过程的任意时刻.该可逆调试器,可以解决大型软件和操作系统内核...     

支持多种并行程序设计模式的可移植并行调试器设计与实现

MPDG是为高性能并行巨型机系统设计的调试工具,其设计指导思想是：1．采用Client/Server结构,实现系统的可移植性,具体表现为将用户界面,并行调试管理与调试监控服务分离,调试监控采用目标系统支持的调试器;2．以同一的使用方式支持多种并行程序设计模式应用,针对共享内存的并行目标应用（如OpenMP程序)和基．于水息传递的分布式目标应用（如PVM或MPI程序）,提供风格完全一致的调试手段;3．实现图形用户界面,MPDG的GUI分为3级,即主界面,进程集,单个进程,进程集控制特别适合具有相同执行流和用户视图的并行进程的调试。     

嵌入式系统软件开发环境中调试器的设计

调试在软件开发流程中是一个比较重要的环节,调试器是衡量一个软件开发环境优劣的重要因素.本文对嵌入式系统软件开发环境、软件调试、调试器设计所遵循的基本原理以及嵌入式系统中软件调试的特点作了一个概述.     

A debugger for Ada tasking

The capabilities needed in an Ada debugger are discussed in light of the language's tasking constructs, and the design for a debugger is presented which operates in concert with a single-processor Ada interpreter. This debugger design demonstrates the extensions to sequential debugging techniques that are necessary to handle concurrency, and shows that significant debugging functionality can be provided even without the inclusion of automatic error diagnosis methods. The issues considered include isolation of effects and display of the full dynamic execution status, both of which are essential to diagnosis of concurrent programs     

Replay-based debugging of occam programs

Parallel programs are intrinsically non-deterministic, and therefore the techniques of cyclical debugging that are commonly used for sequential programs are not suitable for parallel ones. This paper proposes a method to reproduce Occam program behaviour. Saving information on the timer values input by the program and the guards selected at run-time on alternative commands allows program replay, i.e. it makes it possible to re-execute the program deterministically with the same inputs following the same instruction path. This enables the software developer to use tools such as debuggers and intrusive monitors to help identify program faults. After discussing possible implementations of the proposed technique, IRD (an interactive replay debugger for Occam programs) is described. Finally, the use of the IRD in a sample debug session is presented as an example.     

Guard: A Relative Debugger

A significant amount of software development is evolutionary, involving the modification of already existing programs. To a large extent, the modified programs produce the same results as the original program. This similarity between the original program and the development program is utilized by relative debugging. Relative debugging is a new concept that enables the user to compare the execution of two programs by specifying the expected correspondences between their states. A relative debugger concurrently executes the programs, verifies the correspondences, and reports any differences found. We describe our novel debugger, called Guard, and its relative debugging capabilities. Guard is implemented by using our library of debugging routines, called Dynascope, which provides debugging primitives in heterogeneous networked environments. To demonstrate the capacity of Guard for debugging in heterogeneous environments, we describe an experiment in which the execution of two programs is compared across Internet. The programs are written in different programming languages and executing on different computing platforms. © 1997 by John Wiley & Sons, Ltd.     

A debugger for concurrent programs

This paper reports on an experimental debugger for concurrent programs. Design objectives include a showing of greatest usefulness when dealing with multiprocess interactions, creation of a simplified more approachable interface for programmers, allowance for the systematic organization (and limitation) of debugging information by programmers, reflection of a natural view of concurrency, and portability. The design responds to a perceived need for debugging techniques applicable in systems of concurrent, communicating, asynchronous processes. During debugging sessions, a user is able to dynamically explore interprocess synchronization points, parallel actions and deadlock situations. The programmer interface is based on a transparent window multiplexer providing a set of windows for each concurrent process. The window manager interactively maps interesting windows to programmer-specified viewscreen locations, while relegating temporarily uninteresting windows to the background. In implementing a debugger for concurrent programs, a principal concern is the probe effect, or the possibility that the debugger itself masks synchronization errors in the program being debugged. For the examples explored, the probe effect was not observed to limit the localization of implanted synchronization errors.     

A database model of debugging

Debugging a program can be viewed as performing queries and updates on a database that contains program source information as well as the state of the executing program. This approach integrates the facilities of a traditional debugger into a programming environment by providing access to runtime information through normal database query operations. We are building a programming environment in which all program information is stored in a relational database system. This system will include capabilities to provide the programmer a simple yet powerful mechanism for describing debugging requests.     

An experiment in tool integration: The DDBG parallel and distributed debugger

This paper discusses the development of a debugging tool for parallel programs showing how the requirements posed by high-level tools for parallel program development have influenced the design of the debugging system since its early stages of development. We concentrate our attention upon the interfacing of the debugger with other tools of a parallel software engineering environment, namely a graphical programming language and a testing and debugging tool. This is illustrated with the results of our experimentation with the design and implementation of DDBG, a debugger for the PVM environment.     

Detecting nondeterminacy in parallel programs

Methods and tools for detecting nondeterminacy in programs for shared-memory multiprocessors are discussed. The approach described divides the debugging chore into two phases. The first phase uses tools that automatically detect nondeterminacy to debug synchronization errors, assuming it is decided at the outset to make the parallel program determinate. At the end of this phase, it is known that the program is determinate, that timing differences will not affect results, and the debugging sessions are repeatable. In the second phase, an interactive break-point debugger is used to find arithmetic and logical errors. The proposed tools fall into two groups: those that statically analyze the source program and those that analyze an execution trace of the program     

Parallel processing system -Harray-

The parallel processing system -Harray- for scientific computations is introduced. The special features of the -Harray- system described are (1) the Controlled Dataflow (CD flow) mechanism, (2) the preceding activation scheme with graph unfolding, and (3) the visual environment for dataflow program development.The CD flow mechanism, controlling the sequence of execution in two levels—dataflow execution in each processor and control flow execution between processors—is adapted in the -Harray- system. Though dataflow computers are expected to extract parallelism fully from a program, they have many problems, such as the difficulty of controlling the sequence of execution. To solve these problems, the CD flow mechanism is adopted.The preceding activation scheme makes it possible to bypass control dependencies in a program, such as IF-GOTO statements which decrease the parallelism in a program. The flow graph of a program is unfolded to decrease the control dependency and to increase the parallelism.The visual environment helps programmers in the writing and debugging of a dataflow program. The environment consists of a graphical editor of a dataflow graph, and a debugger.These special features of the -Harray- system and its execution mechanism are described.     

GDB事件机制的深入分析

介绍gdb的总体结构,在gdb自身进行调试的基础上,结合gdb源代码详细分析gdb的运行过程中的事件机制.对于gdb调试原理的研究,特别是基于gdb的嵌入式系统调试器的研究,具有较大的参考价值.     

A debugger for distributed programs

Developing a distributed debugger is much more complex than developing a sequential debugger. This added complexity is mainly due to the non-determinism of events that communication delays introduce into distributed systems. We explore the problems that one must address when designing a distributed program debugger and then describe our design and implementation of DPD (distributed program debugger). Problems addressed include non-determinism of events, finding consistent system states, setting breakpoints, recording events, and checkpointing. Important features of DPD include dynamic roll back and replay, as well as a graphical user interface. DPD has been tested successfully in debugging distributed programs within a distributed facility called REM (remote execution manager).     

Distributed debugging for mobile networks

Debuggers are an integral part, albeit often neglected, of the development of distributed applications. Ambient-oriented programming (AmOP) is a distributed paradigm for applications running on mobile ad hoc networks. In AmOP the complexity of programming in a distributed setting is married with the network fragility and open topology of mobile applications. To our knowledge, there is no debugging approach that tackles both these issues. In this paper we argue that a novel kind of distributed debugger that we term an ambient-oriented debugger, is required. We present REME-D (read as remedy), an online ambient-oriented debugger that integrates techniques from distributed debugging (event-based debugging, message breakpoints) and proposes facilities to deal with ad hoc, fragile networks – epidemic debugging, and support for frequent disconnections.