Browse Prior Art Database

Source Debug View Information Architecture

IP.com Disclosure Number: IPCOM000106009D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 133K

Publishing Venue

IBM

Related People

Gordhamer, SL: AUTHOR [+4]

Abstract

A general solution for storage of program debugging information as modified through the phases of a compilation process is disclosed. Storage requirements of debugging data are minimized while retaining full source reference capability to allow debugging at any stage produced during the compilation process.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 40% of the total text.

Source Debug View Information Architecture

      A general solution for storage of program debugging information
as modified through the phases of a compilation process is disclosed.
Storage requirements of debugging data are minimized while retaining
full source reference capability to allow debugging at any stage
produced during the compilation process.

      When debugging a program, most state-of-the-art debuggers allow
the program source to be shown.  Most debuggers have at least one
"view" of the source, or how it is shown on the screen.  Example
views might be the source as typed in by the programmer, or the
assembly language produced by the compiler.

      This disclosure describes a technique which allows many
different views to be created, and how they are synchronized so that
text in one view can be correlated with equivalent text in another
view.

      When creating a program, the source code of that program goes
through several steps before a program is produced.  An example of
such steps is seen in the figure.

      Each step of program creation produces some output, and it is
desirable to be able to view the program in terms of this output.

o     The application programmer would like to be able to debug the
       program at the C Source Code or the Expanded C Code level.
    These
       two "views" of the program would allow the programmer to see
    the
       expansion of any macros defined in the program.

o     A compiler writer, or someone interested in
    performance-critical
       applications would like to see the intermediate code produced.
       This would help in the fixing of compiler bugs or compiler
       performance problems.

o     The Machine or Assembly Language view would be useful to the
       writer of the translator.  It would also be of interest to
    those

       concerned with performance.

      There are several difficulties when providing such views:

o     Where will the text be stored?  How can the amount of disk
    storage
       needed to hold all these views be reduced?

o     How can the text in one view be correlated with that of other
       views?  For example, if the user is looking at a particular
    piece
       of machine code, how can that user easily determine which
    source
       statement or intermediate statement produced it?

o     How can the scheme be general enough to ensure that any number
    of
       views from any number of processors can be produced?  How can
    this
       be done without the processors knowing which other processors
    are
       also running.  For example, how can the assembler produce a
    view
       and correlate it with that of a C compiler, without knowing
    that a
       C compiler was actually run previously?

The remainder of this paper w...