Framework for combined compile-time and runtime error checking in Open64 Jianxin Lai, Peng Yuan, Hongmei Wang, Dingfei Zhang Unix System Lab, Hewlett-Packard Company {Jianxin.lai, peng.yuan, hong-mei.wang, zhang.ding-fei}@hp.com Abstract inter-procedural analysis (IPA) framework. The framework provides the facility to instrument the intermediate representation A lot of techniques have been developed to detect errors in (WHIRL) for runtime checking and perform both intra- and program automatically. Static checkers scans the program source inter-procedural data flow analysis for static checking. The code to find potential problems. Runtime checkers changes the protocol to pass the analysis result from static checker to runtime executable statically by compile-time instrumentation or checker to guide the instrumentation is also developed. With this dynamically by runtime instrumentation. Static checker tends to new framework, the checkers are able to eliminate the false report false positive warnings and runtime checker shows great positive of static checker while decrease the overhead of the overhead at runtime. runtime checker. In this paper, an Open64 based framework for combined compile-time and runtime error checking is present. Based on the 2. Framework overview framework, the checker for uninitialized variables is implemented. The checker has less runtime overhead than traditional runtime Our framework includes two major components. One is the checkers and don’t issue any false positive warnings. With this runtime checker, which is based on compiler instrumentation. The framework, new checkers are able to make better trade-off program will be instrumented with the interface provided by the between false positive warnings and runtime overhead than any runtime checking library. The runtime checker is designed to traditional approaches. detect the errors in the program during the execution of the program. It’s available at all optimization levels. The other is the Categories and Subject Descriptors D.3.3 [Programming static checker. This part is built in WOPT and IPA. One major Languages]: Processors – compilers. task of the static checker is to calculate the candidate set for runtime checking and pass the information to instrumentation General Terms Algorithms phase. Static checker is able to identify the real safe cases and Keywords open64 compiler, static checker, runtime checker exclude them from the candidate set. Since the safe cases are not instrumented, the overhead of our approach is less than traditional 1. Introduction binary instrumentation based checkers. Another task is to identify the real unsafe case and issue warnings to programmer. Thus the A lot of techniques have been developed to detect errors in false positive warnings are eliminated. With the collaboration of program automatically. Basically, the corresponding tools utilize the two parts, we can make better balance between the accuracy two basic approaches for error checking. One is checking the error and overhead than before. by scanning the source code, aka static checker. The static checker The whole framework is based on existing open64 doesn’t require running the program during checking errors in the infrastructure. It includes 4 parts: program. The other is the runtime checker, which starts the - Instrumentation phase program in a managed environment and performs the checking - Library for runtime checking (librtc) while the program is running. - Static checking phase in WOPT enabled at O2 and O3 The static checker has a lot of advantages over the runtime - Static checking phase in IPA checker. It can be integrated with the development environment easily, check the program during the coding phase and is able to check part or whole of the source code regardless the program is executable or not. Static checker can also cover all code in the program regardless it is executable or not. The major disadvantage of static checker is the accuracy. Static checker may either miss real errors or issue false positive warnings. On the contrary, the runtime checker doesn’t report any false positive warnings but it usually has noticeable overhead. Also, runtime checker is only able to detect errors in the executed code. In this paper, a framework combining compile-time and runtime error checking to detect errors in program will be presented. The framework is based on Open64 [1] in order to leverage the compiler infrastructure, static single assignment form (SSA) based data flow analysis in global optimizer (WOPT) and C/C++/F 2.4 Static checking phase in IPA Open64 IPA framework enables inter-procedural analysis and optimizations. But the current IPA framework is not context FE sensitive and the support for inter-procedural data flow analysis is -IPA -O2 limited. In the new framework, the current open64 IPA infrastructure is enhanced to support context-sensitive and partial flow-sensitive inter-procedural analysis. The new IPA IPL infrastructure is flexible to control the analysis scope to be either WOPT IPA whole program or partial program. The static checkers built on the -O0/1 new IPA infrastructure are able to perform checking in a larger scope with flexible resource control. Similar to existing Open64 IPA, the new IPA infrastructure Instrument librtc also includes two phases: local summary phase (IPL) and IPA phase. In IPL phase, the summary information for the PU is collected and written into the fake object file. To achieve context CG sensitivity, each call site will be summarized separately regardless if they call the same function or not. To achieve flow sensitivity, Figure 1. Framework overview the SSA versions of function parameters and chi nodes of global variables associated to the call site are also summarized. The SSA 2.1 Instrumentation phase versions of global variables on the RETURN statement are The instrumentation phase is activated at all optimization summarized to model the side effect of the function. Also, the levels. In general, it walks the whole WHIRL tree and instruments checker can have an IPL phase to summarize the information the WHIRL node based on the checker’s requirement. This phase needed for the IPA phase. In IPA phase, the call graph will be also creates new symbols and makes the right layout for all built using the call site summary information. On the call graph, variables used by the checking functions defined in the runtime the SSA versions of actual and chi nodes of global variables will library. This phase includes 2 steps. Step 1 is the candidate be applied to the edges of the call graph. Once the call graph is selection. If the static checker in either WOPT or IPA is available, built, the SSA versions of the RETURN statement will be applied candidate set is provided by the static checker. Otherwise all to the call graph using a bottom-up approach. All chi nodes on the possible cases will be included in the candidate set. Step 2 is the edge will be checked. If the symbol of the chi is not changed in transformation. All candidates will be instrumented for runtime the callee, the result version of the chi node will be replaced by checking. the operand version. All occurrences of the result version will be replaced in all the summary information of the caller. Then we 2.2 Library for runtime checking (librtc) can treat the call graph as control flow graph and perform classic The runtime library provides the functionality to check errors SSA construction algorithm on it to construct the global SSA. If at runtime. For different checkers, different checking functions are the callee has multiple call sites, a entry phi node will be needed. Also, the instrumentation phase requires the interfaces introduced to replace the entry chi. The number of the operands of provided by the librtc to generate the right function call at the the entry phi node equals to the number of in-edges of the callee. right position on the IR. The version of the operand matches to the result version of chi node on the edge. 2.3 Static checking phase in WOPT WOPT builds hashed static single assignment form (HSSA) and does data flow analysis on top of the HSSA representation [2]. Symbol resolution Entry PHI insertion On HSSA representation, the alias information is represented by chi nodes and mu nodes. The chi nodes are created for global variables around the call sites to model the side effects of the Symtab merge Rename global SSA function call. The mu nodes are created for global variables and attached to the RETURN statement. The entry chi is inserted to the beginning of the program unit (PU) to make sure all uses have Build Callgraph Update summary the definitions. In our framework, the version defined by entry chi is assigned with a special version number. If the call site uses the Propagate special version in either parameters or the chi attached to the call IPA checking node, the variable is not changed on all paths from the function RETURN version entry to the call site. If the mu node on the RETURN statement uses the special version, the variable is not changed in all paths from the entry to exit. Figure 2. IPA phase ordering The framework is built on top of WOPT. It provides methods to traverse the symbol tables, HSSA representation, In the figure 3 below, (A) is the source code. (B) is the Definition-Use (DU) manager and alias manager. The checkers in intra-procedural SSA. (C) is the call graph before applying the WOPT are able to visit the IR and symbol tables by these global SSA construction. (D) is the global SSA representation. interfaces to perform the intra-procedural checking. if the variable is defined or not. At the present of IPA, if the int dbg; int dbg; variable is passed to other functions, a new parameter will be int foo(int x) { int foo(int x) { appended to the end of the parameter list and the address of the int y; int y; flag will be passed by this new parameter.