Browse Prior Art Database

One-Step Trace PreProcessor for C and C++ programs Disclosure Number: IPCOM000014217D
Original Publication Date: 2001-Apr-14
Included in the Prior Art Database: 2003-Jun-19

Publishing Venue



Adding trace points or "instrumentation" data at module entry and exit points is one of the easiest methods one can use to improve the reliability, availability, and serviceability (RAS) characteristics of C and C++ programs. One approach to this problem is to use a C++ trace class as the first local declaration in a given module. The constructor for the trace class may take as its argument the function declaration while the local constructor method contains the logic for printing out the instrumentation data to a predefined trace stream: eg. tracer trace("routine_xyz( )"); coupled with the appropriate constructor results in the following instrumentation data output: "@enter routine_xyz." When paired with the appropriate C++ trace destuctor the local trace class going out of scope will result in the following instrumentation data appearing in the trace stream: "@exit routine_xyz." See Holub "C+C++ Programming With Objects" pg. 145 for details. A more sophisticated class using the same ideas is espoused in Dumpleton's OSE build environment in the OTC_TRACER trace class. Given the simplicity of the instrumentation itself, one barrier to its deployment is the fact that RAS characteristics are seldom built into the code at its inception. What occurs is that the person porting code to a new target platform may be given upwards of 500,000 lines of code with many hundreds of functions, dispersed among many modules in various directories, none of which have been instrumented. The original product implementor may have been a skilled architect of the product being developed. He may also be one of the "digerati cognoscenti" of the reference platform. Unfortunately both of these facts conspire to ensure that all of the nuances, shortcuts, and idioms of the reference platform and product are exploited to the detriment of the porter wishing to get the code to work on the "foreign" platform. What is needed is a tool called a "trace pre-processor" to massage the reference source code into an instrumented form that is easier to debug once the code is up and running. Once the code is up and running and fully debugged the trace code can remain in the source code at no cost in module size. This is done by compiling the source code without the system of defines that enable the trace class deployment. The trace preprocessor (eg. the "invention") is a lex program which contains the logic for placing the "TRACER" class instrumentation data at the correct spots in C and C++ code automatically. Lex is a metacompiler invented by Mike Lesk at AT&T. It is commonly used by compiler writers to generate C programs which implement lexical analysis, eg. the first "pass" over the source code in any typical programming language compiler. Details of the DFA state machine algorithm that the lex program implements for the programmer can be found in Aho's "Principles of Compiler Design" (eg. the "Dragon" compiler book). One can use any of the commonly available C/C++ grammars defined in terms of Unix regular expressions, eg. the "Roskind" grammar or the ANSI language standards themselves as the specification of the left hand side of a lex "pattern." This can be coupled with the following "prototype" right hand side "action" rule. This in and of itself is enough to implement a simple trace pre-processor using any of the "trace" classes described in the first paragraph. lex rules section begins pattern rule for a C module implementation corresponding trace pre-processor action rule