P.T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Univ. of California, Berkeley, 1984. 17  Home/Search   Document Not in Database   Summary   Related Articles   Check

....access, generally. The symbol table provides the debugger with the essential map for interpreting the data in the program s memory hierarchy. To create the symbol tables, the software development tools must deal with two problems related to debugging, the data value and code location problems [37]. The first is concerned with determining the value of a program variable at the current point in program execution, while the second is concerned with determining how processor instructions correlate to high level language statements for source level debugging. After solving these problems, the ....

....assembly instructions to certain pieces of source level code. Additionally, the software development community has dealt with similar issues with debugging software in the presence of optimizations; the two main problems which have been identified are the data value and code location problems[37]. A great wealth of literature is available on solutions to these problems in the software debugging area, much of which might be applicable to debugging FPGA hardware despite the fact that software has chiefly sequential semantics and hardware often has a mixture of sequential and parallel ....

P. T. Zellweger, Interactive Source-Level Debugging of Optimized Programs, PhD thesis, University of California, Berkeley, May 1984, This work is also available as Technical Report CSL-84-5 from Xerox PARC.

....used with code not optimized by the compiler. Since bugs may still appear in prototype versions of a program, where optimization is desirable, there is a need for debugging optimized programs. An interactive breakpoint based debugger able to deal with optimized code must handle two major problems [Zel84]: The code location problem occurs as soon as the user sets a breakpoint on a source line. Then the debugger must decide where to stop the object program. Once the program has been stopped the user usually wants to inspect the program variables. The debugger must be able to compute the values the ....

....by itself. This can be done by calculating the set of reaching definitions of v. The variables written by the corresponding stores in the object program are those that correspond to v. ffl In contrast to other algorithms that require the program to be stopped at syntactic breakpoint locations [Zel84], our algorithm can be used at arbitrary points in a program, given by a pair (b s ; b o ) of locations in the source and object code. This is motivated by the fact that syntactical breakpoint locations are neither easy to find nor unique and may even not exist. However, as long as the breakpoint ....

P. T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. Technical Report CSL-84-5, Xerox Corporation, Palo Alto Research Center, Palo Alto, California, May 1984. 5

.... during an interactive debugging session, the region of code that is to be debugged ( FM80] ZJ90] and ffl to have the compiler provide information about the optimizations that it has performed and to have the debugger use that information to provide appropriate behavior ( WS78] Hen82] [Zel84], CMR88] ZJ90] Gup90] PS91] Coh91] CM91b] BHS92] PS92] Cop92] BW93] AG93a] A larger problem is lowering the cost of debugging production quality software. Much if not most production quality software produced in this country is heavily optimized, and the first approach, ....

....5.1: Line Table Code Address Source Line Number . 3F6 17 3FC 18 404 19 . 5. code modification At a higher level, how the debugger presents information about the program to the user becomes a more difficult problem in the presence of optimization. Zellweger [Zel84] introduced terms for two methods of removing or ameliorating the confusion introduced into the debugging process by optimization. The preferred method is to have the debugger responses to queries and commands on an optimized version of a program be identical to its responses to the same set of ....

[Article contains additional citation context not shown here]

P. Zellweger, "Interactive Source-Level Debugging of Optimized Programs," Research Report CSL-84-5, Xerox Palo Alto Research Center, Palo Alto, CA, May 1984.

....is useful mainly for inquiries about variables, to determine their value or to make changes to them. It is by far more used than the address mapping. The address mapping is useful for 1 The full treatment of the problems of debugging optimized code is still an open research area [Hennessy, 1982] [Zellweger, 1984], Wall,1985] 2 watching addresses being unintentionally touched to determine the name of the corresponding variable. The target mapping is used when the program counter of the target process has to be interpreted in terms of the source program. For example when printing the call stack, the ....

....expanded subprogram is reached, the debugger has to should display the virtual runtime stack, that is, all the activation records that would be on the runtime stack if subprograms would not be inline expanded. To achieve this, a virtual frame table (called inline table in [Zellweger, 1983] [Zellweger, 1984]) is introduced and the target and source mappings are modified slightly. The virtual frame table records information whenever the compiler expands a subprogram call inline. Each table entry contains three items: a pointer to the source location of the call (CallingLocation, a pointer to the ....

P. T. Zellweger, "Interactive Source-Level Debugging of Optimized Programs", Ph.D. Thesis, University of Berkeley, Department of Computer Science. Available as Technical Report CSL-84-5, XEROX Corporation, Palo Alto Research Center, May 1984. i

....environment but are much more difficult to achieve in a highperformance optimizing compiler environment, particularly one based on aggressive inlining. Other researchers have investigated the problem of enabling compilation and optimization to coexist gracefully with the programming environment [Hen82, Zel84, CMR88, ZJ91]. This chapter describes the techniques used in the SELF implementation to support the programming environment, focusing on the support provided by the compiler. A compiled method contains more than just instructions. First, it includes a list of the offsets within the instructions of embedded ....

Polle T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. Ph.D. dissertation, Computer Science Department, University of California, Berkeley, 1984. Also published as Xerox PARC Technical Report CSL-84-5, May, 1984.

....number of executable binaries being highly optimized, it has become a necessity to provide a clear and correct source level debugger for programmers to debug optimized code. In general, there are two ways for an optimized code debugger to present meaningful information of the debugged program [1]. It provides expected behavior of the program if it hides the optimization from the user and presents the program behavior consistent with what the user expects from the unoptimized code. It provides truthful behavior if it makes the user aware of the effects of optimizations and warns of ....

....the new code location mapping scheme. Section 3 describes how our forward recovery model works. Section 4 discusses some of the previous works and compares our approach with them. Section 5 contains our conclusions. 2 Code location mapping A debugger usually uses two kinds of code mappings [1, 2]: the object to source mapping which the debugger uses to report the faulty statement when an exception occurs, and the source to object mapping which the debugger uses to determine where to suspend the normal execution and decide if a source breakpoint should be reported. Since we are only ....

[Article contains additional citation context not shown here]

P. T. Zellweger, Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Electrical Engineering and Computer Sciences, University of California, Berkeley, CA 94720, 1984.

....therefore necessary, upon occasion, to either debug optimized code or never optimize the code. Were it not for the confusion optimization can introduce into debugging, debugging optimized code would generally be preferable to debugging unoptimized code and adding recompilation steps. 4 Zellweger [Zel84] introduced terms for two methods of removing or ameliorating the confusion introduced into the debugging process by optimization. The preferred method is to have the debugger responses to queries and commands on an optimized version of a program be identical to its responses to the same set of ....

.... debugging session, the region of code that is to be debugged ( FM80] ZJ90] and ffl to have the compiler provide information about the optimizations that it has performed and to have the debugger use that information to provide appropriate behavior ( WS78] Hen82] Ze83a] Ze83b] [Zel84], CMR88] PS88] Cop90] ZJ90] PS92] A larger problem is lowering the cost of debugging production quality software. Much if not most production quality software produced in this country is heavily optimized, and the first approach would result in compilers that would not get used; their ....

[Article contains additional citation context not shown here]

P. Zellweger, "Interactive Source-Level Debugging of Optimized Programs," Research Report CSL84 -5, Xerox Palo Alto Research Center, Palo Alto, CA, May 1984.

.... during an interactive debugging session, the region of code that is to be debugged ( FM80] ZJ90] and ffl to have the compiler provide information about the optimizations that it has performed and to have the debugger use that information to provide appropriate behavior ( WS78] Hen82] [Ze83a], Ze83b] Zel84] CMR88] PS88] Cop90] ZJ90] PS92] A larger problem is lowering the cost of debugging production quality software. Much if not most production quality software produced in this country is heavily optimized, and the first approach would result in compilers that would ....

P. Zellweger, "Interactive Source-Level Debugging of Optimized Programs," Research Report CSL83 -1 , Xerox Palo Alto Research Center, Palo Alto, CA, Jan. 1983.

....There are two primary aspects associated with code optimization The author is currently with Compaq Computer Corporation, Shrewsbury, MA. To appear in the 1999 ACM SIGPLAN Conference on Programming Language Design and Implementation, Atlanta, Georgia, May 1 4, 1999. that make debugging difficult [1]. First, it complicates the mapping between the source code and the object code due to code duplication, elimination, and reordering. This problem is called code location problem. Second, it makes reporting values of source variables either inconsistent with what the user expects or simply ....

....Also register allocation algorithms which reuse registers or memory locations may make variable values non existent. This problem is referred to as data value problem. In general, there are two ways for an optimized code debugger to present meaningful information about the debugged program [1]. It provides expected behavior of the program if it hides the optimization from the user and presents the program behavior consistent with what the user expects from the unoptimized code [2, 3, 4] It provides truthful behavior if it makes the user aware of the effects of optimizations and warns ....

[Article contains additional citation context not shown here]

P. T. Zellweger, Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Electrical Engineering and Computer Sciences, University of California, Berkeley, CA 94720, 1984.

....production use, at a point when it should be optimized. Figure 1 shows a fragment of a C program together with its corresponding Sparc assembly code 1 . Using this example, we will demonstrate some of the problems a symbolic debugger for optimized code must deal with. The code location problem [Zel84] arises as soon as the programmer sets a breakpoint. If he wants to break at line 4, where should the debugger halt the optimized program The appropriate mapping depends on the programmer s intention in setting the breakpoint. If he wants to examine the old value of f the program should be ....

....during program development, they are of limited use for debugging production code or if bugs only show up in fully optimized code. In these cases optimization must be handled by the debugger. Additional symbol tables can inform the debugger of the effects of the transformations applied [Zel84, CMR88, BHS92]. Different transformations often require different tables that must be updated in each optimization step, so the debugger depends on the optimizer s implementation and usually handles only few optimizations. Furthermore, tables cannot easily support different breakpoint mappings or the use of ....

P. T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. Technical Report CSL-84-5, Xerox Corporation, Palo Alto Research Center, Palo Alto, California, May 1984.

....causes variable y being updated prematurely. Also instruction I6 which should have been executed in order to obtain the expected value of variable a has not been executed at this point. Even though there have been different object breakpoint mapping schemes proposed such as semantic breakpoints [2], syntactic breakpoints [2] and statement labels [3, 4] each of which maps a source breakpoint to a different place in the object code, the fundamental problem of this traditional scheme remains only the program state of a single point is available. There Technical Report IMPACT 98 01 2 ....

....prematurely. Also instruction I6 which should have been executed in order to obtain the expected value of variable a has not been executed at this point. Even though there have been different object breakpoint mapping schemes proposed such as semantic breakpoints [2] syntactic breakpoints [2], and statement labels [3, 4] each of which maps a source breakpoint to a different place in the object code, the fundamental problem of this traditional scheme remains only the program state of a single point is available. There Technical Report IMPACT 98 01 2 breakpoint source line # S3: ....

P. T. Zellweger, Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Electrical Engineering and Computer Sciences, University of California, Berkeley, CA 94720, 1984.

....This approach can present a problem with floating point numbers which use an inexact representation. Debuggers are ideally suited for comparing program execution. They can control the program execution, access the program s state and the relevant type information, and do not require source code [4, 6, 17, 23, 24, 25, 33]. These capabilities of debuggers can overcome the limitations of the manual and the file comparison approaches. This paper describes our relative debugger, called Guard 1 . In addition to ordinary debugging commands, Guard provides new commands for relative debugging. First, we present novel ....

P. T. Zellweger. Interactive source-level debugging of optimized programs. Technical Report CSL-84-5, Xerox PARC, 1984.

.... solution is to use no debuggers at all. Myers from the National Security Agency states that one reason for them to use print statements for debugging is that debuggers don t work with optimized code [Mye91] A debugger able to handle optimized code must provide solutions for two major problems [Zel84] The code location problem is related to the mapping between lines or statements of the source program and instructions in the object code. If a programmer sets a breakpoint on a source line, the debugger must be able to decide where to stop the object program. If the program raises an ....

.... mappings, the semantical mapping, where [ the corresponding object code is the object code that performs the operation specified by the program statement and the syntactical mapping [ that preserves the position of a statement with respect to its neighboring statements [Zel84] In fig. 1 it is clear that the semantical mapping of line 4 is instruction 2. However, it is not easily seen what the syntactical mapping should be. There are several possibilities, e.g. instruction 10,11 or 12 (since they are in the same conditional branch) instruction 8 (since that is the ....

[Article contains additional citation context not shown here]

P. T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. Technischer Bericht CSL-84-5, Xerox Corporation, Palo Alto Research Center, Palo Alto, California, May 1984.

....the callers s stack frame and symbol table information given the called routine s stack frame. Subsequently, only providing a correct call stack trace is discussed. In particular, we do not further discuss the display of local variables. This problem has not been not discussed in the literature. [Zel84] provides a solution to the problem of providing a correct call stack trace in the presence of procedure integration (inlining) This paper shows how an optimizing compiler and interactive debugger can cooperate so that the debugger can provide an accurate call stack trace while making subroutine ....

....F 2 s temporaries F 3 s local variables F 3 s temporaries F 2 F 3 Figure 2.3: Optimized Call Stack 4.1 The Debugger Maintains Its Own Frame Pointers The debugger can maintain its own copy of the information that it currently gets from the call stack. The debugger uses invisible breakpoints ([Zel84]) to collect the information. A invisible breakpoint is a breakpoint at which the debugger halts the executing program, takes some action, and continues execution without ever giving control to the user. As we have seen, in order to construct the call stack trace, the debugger needs for each ....

P. Zellweger, "Interactive Source-Level Debugging of Optimized Programs," Research Report CSL84 -5, Xerox Palo Alto Research Center, Palo Alto, CA, May 1984.

....maintain the illusion that the code is not optimized, and in so doing, allow the user to infer from the current location the overall state of the computation. Zellweger managed to achieve this for procedure in lining, even going so far as to have the in lined procedure appear on the call stack [30]. When not possible, inform the user by some appropriate means how the actual state of the program differs from the apparent (i.e. non optimized) state. In the literature I have seen, this means printing out a message to explain the situation. This is typified in the DOC debugger which ....

Zellweger, P., Interactive Source-Level Debugging of Optimized Programs, Ph.D. Dissertation, Computer Science Division -- EECS, University of California, Berkeley, CA, 1984

....debugging and conversational computing. 3.3.1 Debugging Introspective capabilities are useful in debugging. Using the mechanisms of introspection, a director that serves as a powerful debugger can be implemented. An extensive survey of the debugger s functionality is provided by Zellweger [183]. In an introspective system, the executor is the program being debugged and the director functions as a debugger. An introspective framework has several features that are useful in debugging: unobtrusive monitoring, reverse execution, and high level modifications of the executor s state. Because ....

....level statements and displays them on the screen is described in Sections 3.1.1 and 3.1.2. Some constructs from the source code are impossible to detect, because they are not represented in machine code or they are mixed with other constructs. This is especially the case with optimizing compilers [183]. A partial solution is to maintain a parse tree describing the abstract syntax of the program [164] This parsing tree can provide a detailed link between source code and machine code. Unfortunately in common compiled languages, the parsing tree is thrown away after the compilation process is ....

P. T. Zellweger. Interactive source-level debugging of optimized programs. Technical Report CSL-84-5, Xerox PARC, 1984.

....for example, performance would be abysmal [Cha92] But an interactive programming environment also demands rapid turnaround time and complete source level debugging. To make SELF practical, the system must provide interpreter semantics at compiled code speed, combining expected behavior [Zel84] with global optimization. Most existing systems do not support the debugging of optimized code. Programs can either be optimized for full speed, or they can be compiled without optimizations for full source level debugging. Recently, techniques have been developed that strive to make it possible ....

....Most existing systems do not support the debugging of optimized code. Programs can either be optimized for full speed, or they can be compiled without optimizations for full source level debugging. Recently, techniques have been developed that strive to make it possible to debug optimized code [Hen82, Zel84, CMR88]. However, none of these systems is able to provide full source level debugging. For example, it generally is not possible to obtain the values of all source level variables, to single step through the program, or to change the value of a variable. Optimization is given priority over debugging, ....

[Article contains additional citation context not shown here]

Polle T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. Ph.D. dissertation, Computer Science Department, University of California, Berkeley, 1984. Also published as Xerox PARC Technical Report CSL-84-5, May 1984.

....the executions of two almost identical codes, seeking to identify the source of a small discrepancy. Debuggers assist in locating program errors. They are tools which allow a user to investigate the execution state of an application program, by for example examining the state of program variables [11, 12, 13, 17]. Significant recent extensions include graphical user interfaces to improve the ease of use, data visualization facilities to aid the interpretation of large and complex data structures, the concept of process groups to aid the management of many independent threads in parallel machines, and ....

P. T. Zellweger. Interactive source-level debugging of optimized programs. Technical Report CSL-84-5, Xerox PARC, 1984.

....technology is ideally suited for building a tool to support the process of software evolution by providing necessary primitives for comparing program execution. Debuggers can control the program execution, access the program s state and the relevant type information, and do not require source code [6, 8, 18, 25, 26, 27, 34, 35]. These capabilities of debuggers can overcome the limitations of the manual and the file comparison approaches. This paper describes our relative debugger, called Guard 1 . In addition to ordinary debugging commands, Guard provides new commands for relative debugging. We discuss some conceptual ....

P. T. Zellweger. Interactive source-level debugging of optimized programs. Technical Report CSL-84-5, Xerox PARC, 1984.

....debugger s source code view. A source level debugger must solve two types of problems: First, the debugger must map a source statement to an instruction in the object code to set a breakpoint and map an instruction to the source code to report a fault or user interrupt (code location problems [26]) Second, the debugger must retrieve and display the values of source variables in a manner consistent with what the user expects with respect to the source statement where execution has halted (data value problems [26] When a program has been compiled with optimizations, mappings between ....

.... the source code to report a fault or user interrupt (code location problems [26] Second, the debugger must retrieve and display the values of source variables in a manner consistent with what the user expects with respect to the source statement where execution has halted (data value problems [26]) When a program has been compiled with optimizations, mappings between breakpoints in the source and object code become complicated, and values of variables can be inaccessible in the runtime state or inconsistent with what the user expects. This paper presents a solution to deal with the the ....

[Article contains additional citation context not shown here]

P. Zellweger. Interactive Source-Level Debugging of Optimized Programs. PhD thesis, University of California, Berkeley, May 1984. Published as Xerox PARC Technical Report CSL-84-5.

No context found.

P.T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Univ. of California, Berkeley, 1984. 17

No context found.

P.T. Zellweger. Interactive Source-Level Debugging of Optimized Programs. PhD thesis, Univ. of California, Berkeley, 1984. 11

No context found.

Zellweger, P., "Interactive Source-Level Debugging of Optimized Programs", Ph.D. Dissertation, University of California, Berkeley, Xerox PARC TR CSL-84-5, May 1984

No context found.

P. Zellweger. Interactive Source-Level Debugging of Optimized Programs. PhD Thesis, University of California, Berkeley, May 1984.

No context found.

P. Zellweger, "Interactive Source-Level Debugging of Optimized Programs," Research Report CSL83 -1 , Xerox Palo Alto Research Center, Palo Alto, CA, Jan. 1983.

First 50 documents

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