LINTON, M. A. 1990. The evolution of Dbx. 211--220.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of 10 elements in the range of 0 to 7. The initial value of the vector key and the values for count, start, and rank computed in the second, third, and fourth loops, respectively, would be: key [0. 9] count [0. 7] st art [0. 7] rank[0. 9] A parallel version of Eo] El] E2] E3] E4] 5] 6] [7] [8] 9] 1 2 4 5 3 3 6 7 4 5 0 1 1 2 2 2 1 1 0 0 1 2 4 6 9 0 1 4 7 2 3 9 5 6 the code for the MTA looks like: count[i] O; count[key[i] start [0] O; for (i = 1; i key value bound; i ) starts = sync int ) start; #pragma tera assert parallel for (i = O; i nkeys; i ) ....

Mark Linton. The evolution of DBX. In USEVIX Summer Oofevece 1990.

....interfaces like X [3] which are available on a range of platforms, and thus provide a high level of infrastructure on different systems. In combination with standard programming languages, these tools are quite effective and can increase productivity significantly. However, debuggers such as dbx [4, 5, 6] and gdb [7] and others [8, 9, 10, 11, 12] do not emphasise the debugging and testing of applications developed with evolutionary engineering techniques. Debuggers of this type allow the user to manipulate the new program through process control commands, and to examine and modify the state of ....

M. A. Linton, 'The evolution of Dbx', Proceedings of the Summer 1990.

....of debugging has been documented by a great deal of research in several research and development communities, including compilers and computer architecture, By far the most comprehensive treatment of debugging has been conducted in the software compiler domain. Several debuggers, such as Dbx [Lin90], has been widely used. Currently the major emphasis in the software compilation debugging domain is on integration between optimization technique based on transformations or aggressive scheduling techniques and debugging process [Shu93] Numerous controllers and DSP processors are supported by ....

M.A. Linton, "The evolution of Dbx", USENIX Conference, pp. 211-220, 1990.

....things when designing a monitor are how to obtain information from, and how to access, the target program. It is very important to solve these problem in an efficient way to reach a good quality in your monitoring results. The four most common methods to do this are, run time instrumentation [13], manual instrumentation [14] interpreter instrumentation [15] and instrumenting compilers [16] 41 Run time instrumentation means that you make the adjustments in the target program code prior to or during execution. These adjustments are often that you replace an instruction with a jump or ....

....written in the language that the compiler recognize. Execution Models There are a lot of different models for the relationship between the monitor and the program being monitored. However, it is possible to distinguish three main models: the one process model [14,17] the two process model [13,18] and the thread model [19] In the one process model, the monitor runs in the same process as the target program. The advantages of the one process model are, simple, highest performance arrangement and that the monitor has convenient access to the program being monitored. The disadvantages are, ....

M. A. Linton, "The Evolution of Dbx", Proceedings of the Summer 1990 USENIX Conference, pages 211-220, June 1990

....of debuggers in existence, there is not a tremendous amount of literature available that discusses how to provide standard debugging functionality. Vern Paxson provides a good survey of debugging techniques in [50] Mark Linton describes issues in the development of the commercial Dbx debugger in [46], and a document exists that describes the internals of the GNU debugger, gdb [51] Dynascope is a research project that undertook to provide a suite of debugging functionality with an architecture independent interface in the form of an object code library [58] The di#culty in using such a ....

Mark A. Linton. The evolution of Dbx. In Proceedings of the USENIX Summer Conference, pages 211--220. USENIX, June 1990. In Anaheim, California.

.... level as that in which the program was written, in which case the conditional breakpoint becomes extremely powerful (though difficult to implement efficiently) Conditional breakpoints have historically often been extremely inefficient, leading perhaps to an underappreciation of their value [2]. In our survey we will pay especially close attention to support for efficient conditional breakpoints. A particularly difficult to find type of bug is a sporadic one: one that is not readily reproducible. These bugs can be due, for example, to referencing uninitialized memory, to interprocess ....

....services (reading and writing of multiple data words and registers) they were able to reduce the number of ptrace calls by 2=3. Linton, the author of dbx , and Olsson et al. also stress the need to reduce the number of system calls and context switches in order to achieve good debugger response [2, 31]. Context switches can be greatly reduced by making the debuggee s state directly available via system calls. For example, the proc mechanism supported in System V Release 4 Unix systems [32] provides a virtual file system directory in which there is a file for each process. The contents of the ....

[Article contains additional citation context not shown here]

Mark A. Linton. The evolution of dbx. In Proceedings of the 1990 Usenix Summer Conference, Anaheim, CA, June 1990.

....Special purpose hardware can monitor memory efficiently. Unfortunately, the hardware approach inherently limits the number of data words simultaneously monitored. The Intel i386 can monitor four words; the MIPS R4000 and the Sparc can only monitor a single word. The UNIX debuggers gdb [17] and dbx [14, 18] provide data breakpoints. Both systems conservatively assume all instructions are unsafe. The possible sideeffects of each instruction are checked through dynamically inserted trap instructions. Due to context switch and trap costs, this approach incurs very high overhead. We measured the ....

M. A. Linton. "The Evolution of Dbx,". In Proceedings of the 1990 Usenix Summer Conference, pages 211-- 220, Anaheim, CA, June 1990.

....not affect the behavior or timing of the simulation. Proteus also provides repeatability: users can rerun simulations to pinpoint bugs. Real multiprocessors generally provide neither of these abilities. Because Proteus runs as a single process, it works well with sequential debuggers such as dbx [Lin90] This extends the power of advanced sequential debuggers to the parallel development arena. Furthermore, Proteus provides an internal debugging mode that allows users to examine the states of threads, processors, locks, and memory. Combining the Proteus debugger with a sequential debugger such ....

M. A. Linton. The evolution of dbx. In Proceedings of the 1990 USENIX Summer Conference, pages 211--220, June 1990.

....our efforts on the control of execution and views of the the executing program. To allow programmers to control execution, debuggers provide many different types of breakpoints, variable watches and displays of stack frames. Typically the most feature rich debuggers (such as GDB [16] or DBX [7], two popular UNIX based debuggers) only provide the programmer with a textual representation of structures under investigation. Some graphical frontends to these tools have been constructed (e.g. xxgdb and tgdb) but these tools mainly only add cosmetic features to the output of the underlying ....

M. A. Linton. The Evolution of dbx. In Proceedings of the 1990 Usenix Summer Conference, Anaheim, CA, June 1990.

....in several research and development communities on several levels of abstraction, including compilers, computer architecture, and databases. By far the most comprehensive treatment of debugging has been conducted in the software compiler domain. Several debuggers, such as VAX DEBUG [Bea83] Dbx [Lin90], GDB [Sta91] and more recently Purify [Has92] has been widely used. Majority of efforts related to debugging in the compiler domain has been dedicated to symbolic level debugging on uniprocessor computers. It has been noticed that debugging often significantly slows done execution of the ....

M.A. Linton, "The evolution of Dbx", USENIX Conference, pp. 211-220, 1990.

....intermediate representations and code generator generators. We are developing techniques for building retargetable, multiple target debuggers. This paper describes the design and implementation of ldb, a prototype retargetable debugger. ldb is a source level debugger like gdb or dbx [15, 22]. It can be used with C programs compiled with lcc [11] a retargetable compiler that generates code for the MIPS R3000, Motorola 68020, SPARC, and VAX architectures. Users can set and remove breakpoints, start and stop programs, evaluate expressions, and make assignments to variables. ldb s ....

....debugger are tightly coupled. DEC SRC s Vulcan debugger executes in the same address space as the compiler, sharing its annotated abstract syntax trees. The DICE debugger cooperates with an incremental compiler as part of an integrated environment [12] Most debuggers, like VAX DEBUG [4] and dbx [15], are separate tools which communicate with the compiler only through symbol table information. This information is placed in the object file in a machine dependent format. ldb is like these debuggers, but it uses PostScript as a machine independent, language independent, symboltable format. Most ....

[Article contains additional citation context not shown here]

M. A. Linton. The evolution of Dbx. In Proceedings of the Summer USENIX Conference, pages 211--220, Anaheim, CA, June 1990.

....and start[n 1] 1 inclusive. For example, assume we need to compute the rank of 10 elements in the range of 0 to 7. The initial value of the vector key and the values for count, start, and rank computed in the second, third, and fourth loops, respectively, would be: 0] 1] 2] 3] 4] 5] 6] [7] [8] 9] key[0. 9] 1 2 4 5 3 3 6 7 4 5 count[0. 7] 0 1 1 2 2 2 1 1 start[0. 7] 0 0 1 2 4 6 8 9 rank[0. 9] 0 1 4 7 2 3 8 9 5 6 A parallel version of the code for the MTA looks like: for (i = 0; i keyvaluebound; i ) count[i] 0; for (i = 0; i nkeys; i ) count[key[i] start[0] 0; for ....

....of the internals were rewritten to deal with multiple stream contexts, our symbol tables, program libraries, and compiler optimizations such as parallelization and inlining. We also use a different approach for the tdb process to communicate with the running program. Most conventional debuggers [7, 8] communicate with the running program using a ptrace or proc type mechanism. Here, the operating system intervenes to help obtain information about the program. On the MTA, where stream state is the responsibility of the user level Runtime, having the OS intervene is not necessary or appropriate. ....

Mark Linton. The evolution of DBX. In USENIX Summer Conference, 1990.

....particular implementation of the nub interface might serve more than one compilation system or more than one debugger. For example, a Unix nub implementation that understood Unix style executable files and symbol table formats could support traditional source level debuggers, like gdb [18] and dbx [10], and high level debuggers, like Duel [7] But different debugger design goals would often yield different nub implementations, even on the same architecture. The sections that follow describe cdb and its nub, which were designed to be as machine independent as possible. Example: cdb cdb is a ....

M. A. Linton. The evolution of Dbx. In Proceedings of the Summer USENIX Technical Conference, pages 211--220, Anaheim, CA, June 1990.

....GUIs make this exploration less tedious and more productive, but most are just a veneer over commands that print the values of expressions. Programmers interact with most source level debuggers in the language of the program being debugged, e.g. C debuggers accept and evaluate C expressions [9]. This choice is invariably justified on grounds that the programmer needs to know only one language, and that even small deviations would make a debugger unnecessarily hard to use [1, 8] This paper investigates the contrary view: Programmers are best served by debugging languages that are more ....

....The operators . and specify Duel s with operator; as in C, applies to structures and applies to pointers to structures. In both e 1 .e 2 and e 1 e 2 , e 2 is evaluated within the scope of e 1 . For example, alternation can specify several fields of a structure: gdb duel hash[1,9] (scope,name) hash[1] scope = 3 hash[1] name = x hash[9] scope = 2 hash[9] name = abc The . and operators are quite general, e.g. x : hash[ 1024] 0 = x (if (scope 5) name) prints the name field of the elements in hash that have a scope greater than 5. References to ....

[Article contains additional citation context not shown here]

M. A. Linton. The evolution of Dbx. In Proceedings of the Summer USENIX Technical Conference, pages 211--220, Anaheim, CA, June 1990.

....monitoring, instruction simulators and dynamic linkers. A discussion of related work is presented here. Debugging primitives, which form the core of Dynascope primitives, are usually provided by the operating system [3, 22, 38] Debuggers rely on these primitives to carry out their operations [25, 30, 44]. Because operating systems provide different debugging primitives, debuggers must be carefully engineered to support porting to different platforms [37] Significant amount of research has been carried out recently to provide high level debugging abstractions and languages [12, 35, 36, 49] Some ....

M. A. Linton. The evolution of DBX. In Proceedings of the Summer 1990 USENIX Technical Conference, pages 211--220, Anaheim, 1990.

....we describe software developed for interactively extracting and modifying typed data structures within an executing program, a package dubbed the application executive, or ae for short. The application executive incorporates much of the functionality of the Unix breakpoint debugger dbx [Uni87b, Lin90] or gdb [Sta89a] the breakpoint debugger distributed by Free Software Foundation, namely the ability to interpret arbitrary expressions and access to data objects in different stack frames. It further supports run time definition of new data types and data objects, and extended flow of control ....

Mark A. Linton. The Evolution of Dbx. In Usenix Summer Conference Proceedings, pages 211--220, June 1990.

....interfaces like X [3] which are available on a range of platforms, and thus provide a high level of infrastructure on different systems. In combination with standard programming languages, these tools are quite effective and can increase productivity significantly. However, debuggers such as dbx [4, 5, 6] and gdb [7] and others [8, 9, 10, 11, 12] do not emphasise the debugging and testing of applications developed with evolutionary engineering techniques. Debuggers of this type allow the user to manipulate the new program through process control commands, and to examine and modify the state of ....

M. A. Linton, 'The evolution of Dbx', Proceedings of the Summer 1990, USENIX Conference, June 1990, pp. 211220.

....in the semantics of programming languages and operating systems mean that the code may behave differently on two systems. Because of these practical considerations, it is desirable that software tools are available to simplify the process as much as possible. Traditional debuggers such as dbx [5, 11, 23] and gdb [21] and others [14, 15, 16, 17, 7] do not emphasise the debugging and testing of applications which change during their development cycle. Debuggers of this type allow the user to manipulate the new program through process control commands, and to examine and modify the state of the ....

Linton, M., "The evolution of Dbx", Proceedings of the Summer 1990, USENIX Conference, June 1990, pp. 211-220.

No context found.

LINTON, M. A. 1990. The evolution of Dbx. 211--220.

No context found.

Linton, M. A. The Evolution of Dbx. In Proceedings of the Summer 1990 USENIX Conference, pages 211--220, June 1990.

No context found.

Linton, M. A. The Evolution of Dbx. In Proceedings of the Summer 1990 USENIX Conference, pages 211--220, June 1990.

No context found.

Mark A. Linton, `The evolution of Dbx', Proceedings of the Summer 1990 USENIX Conference, June 1990, pp. 211--220.

No context found.

Mark A. Linton, `The evolution of Dbx', Proceedings of the Summer USENIX Technical Conference, Anaheim, CA, June 1990, pp. 211--220.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC