function pointer analysis for c programs · iii. iv. abstract function pointers are a feature of...

Saarland UniversityFaculty of Natural Sciences and Technology I

Department of Computer ScienceBachelor’s Program in Computer Science

Bachelor’s Thesis

Function Pointer Analysis forC Programs

submitted by

Stefan Stattelmann

on August 28, 2008

Supervisor

Prof. Dr. Reinhard Wilhelm

Advisor

Dr. Florian Martin

Reviewers

Prof. Dr. Reinhard WilhelmProf. Dr. Bernd Finkbeiner

Statement

Hereby I confirm that this thesis is my own work and that I have documentedall sources used.

Saarbrucken, August 28, 2008

Declaration of Consent

Herewith I agree that my thesis will be made available through the libraryof the Computer Science Department.

Saarbrucken, August 28, 2008

iii

Abstract

Function pointers are a feature of the C programming language whose

use obscures the control flow of a program and makes programs hard to

analyze. Existing pointer analyses are able to resolve function point-

ers, but lack the capabilities to precisely distinguish function pointer

variables within complex data structures.

The aim of this work is to develop a function pointer analysis which

achieves this precision. It thereby allows a more precise analysis of

programs with an intense usage of function pointers, as they are quite

common in automotive software.

v

Contents

1 Introduction 11.1 Function Pointers and Program Analysis . . . . . . . . . . . . 11.2 Pointer Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Theoretical Foundations 42.1 Program Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Data Flow Analysis . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Analysis Description 83.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Points-to Mapping . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Updating the Points-to Mapping . . . . . . . . . . . . . . . . . 12

3.4.1 Assignments . . . . . . . . . . . . . . . . . . . . . . . . 133.4.2 Address-of Operator . . . . . . . . . . . . . . . . . . . 153.4.3 Pointer Dereference . . . . . . . . . . . . . . . . . . . . 15

3.5 Language Constructs requiring special handling . . . . . . . . 163.5.1 Pointer Arithmetic . . . . . . . . . . . . . . . . . . . . 163.5.2 Casting . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5.3 Multidimensional Arrays . . . . . . . . . . . . . . . . . 173.5.4 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Implementation 194.1 Implementation Framework . . . . . . . . . . . . . . . . . . . 19

4.1.1 Program Analyzer Generator (PAG) . . . . . . . . . . 194.1.2 ROSE Compiler Infrastructure . . . . . . . . . . . . . . 204.1.3 Static Analysis Tool Integration Engine (SATIrE) . . . 21

4.2 Required Extensions . . . . . . . . . . . . . . . . . . . . . . . 224.2.1 Variable Renaming . . . . . . . . . . . . . . . . . . . . 22

vii

4.2.2 Control Flow Graph Refinement . . . . . . . . . . . . . 224.2.3 External Functions . . . . . . . . . . . . . . . . . . . . 23

4.3 Further Extensions . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 Program Slicing . . . . . . . . . . . . . . . . . . . . . . 244.3.2 Optimistic Analysis . . . . . . . . . . . . . . . . . . . . 25

5 Results 275.1 Test Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 grep . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.2 diction . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.3 gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.4 sim6809 . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.5 Automotive software . . . . . . . . . . . . . . . . . . . 30

5.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Conclusion 336.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

References 35

viii

1 Introduction

1.1 Function Pointers and Program Analysis

Function pointers are a type of the C programming language that allowstoring the address of a program routine within a variable and calling theroutine through this variable. For programs that use function pointers, itcannot be determined directly which functions can be called during a run ofthe program because the runtime values of the function pointer variables arenot known in general. This makes it quite hard to analyze such programs.

The information which function can be called at a given program point isnecessary to construct the interprocedural control flow graph of the program.The control flow graph is required for a flow-sensitive interprocedural pro-gram analysis. Without precise knowledge about function pointers, it is notpossible to construct an exact control flow graph, which will result in eitherimprecise or even wrong results of the analysis that uses the graph.

The effects of function pointers are not only relevant when analyzing a Cprogram, they are also important for analyses on assembly level, since calls offunction pointers in C are in general translated to computed calls on machinelevel by the compiler. In some sense, the effects of the computed calls thatare induced by the use of function pointers in C are much more critical onassembly level. When doing a worst case execution time (WCET) analysison an executable file for example, it is very hard to get precise results whenthe targets of a computed call are not known.

1.2 Pointer Analysis

A pointer analysis tries to determine the possible targets of pointer variablesstatically. Consider the C program in figure 1. For this example, a pointeranalysis should find out that at P1 a points to c and b points to c or d.We say that {c} and {c, d} are the points-to sets for a and b respectively,

1

void f ( i n t x ){

i n t ∗a , ∗b , c , d ;

a = &c ;

i f ( x > 0)b = a ;

e l s eb = &d ;

/∗ program point P1 ∗/}

Figure 1: Example program

as illustrated in figure 2. The result of a pointer analysis is sound if allactual runtime targets of a pointer variable are contained in its points-to set.Accordingly {c} would be an unsound points-to set for b because b mightalso store the address of d at P1, depending on the value of the functionparameter x. A solution is imprecise if a points-to set contains variableswhose addresses are never stored in the pointer during an actual executionof the program. Thus, {c, d} would be a sound, but imprecise solution forthe points-to set of a in this example.

In general, it is not possible to get perfectly precise and sound points-to setsbecause the problem is undecidable ([Lan92], [Ram94]). Therefore, a pointeranalysis has to do some form of approximation, e.g. by calculating sound butimprecise points-to sets.

1.3 Requirements

The goal of this work is to develop a program analysis that can determinepossible values of function pointer variables in real-world C programs. Theanalysis is aimed at programs from an embedded context. Therefore it isassumed in this work that some features of the C programming language donot occur in the analyzed programs because they are not used in practice, asautomotive software rarely uses dynamically allocated memory (MISRA-C).

Furthermore, the analysis should work on the analyzed programs directly,without having to do a lot of program transformations beforehand. Thismakes it easy to map the results back to the program so they can be usedby other analyses, like a WCET analysis.

2

� �

� �

Figure 2: Points-to information

1.4 Approach

The basic idea behind the analysis presented in this work is to calculate apoints-to set for every function pointer variable in the program. This setcontains all memory locations whose address might be stored in the variable.

Since C allows indirect access to variables through their address, it is notsufficient to look only at function pointer variables. Instead, the analysis hasto consider all variables that might modify a function pointer through someform of indirect memory access. As C is not a strongly typed language, it isin general not safe for an analysis to rely on type information. That is whythe analysis described in the following does not use type information exceptfor structural information, e.g. if a variable has a basic type or an aggregatetype (structure or array).

The analysis information is stored in a recursive fashion so it is easy tohandle function pointers that are stored within arbitrarily complex objects,like structures with arrays of function pointers.

1.5 Overview

The remainder of this work is organized as follows: chapter 2 gives anoverview of program analysis in general and existing pointer analyses. Ahigh-level description of the new analysis that is presented in this work canbe found in chapter 3. Chapter 4 contains details about the implementationand the framework that was used for it. The application of the analysis toreal-world programs is discussed in chapter 5. Chapter 6 gives a summary ofthe work and presents possible extensions to it.

3

2 Theoretical Foundations

This section is intended to give a short introduction to program analysis ingeneral and to present some existing analyses for pointers in the C programminglanguage. A more detailed description of the existing approaches to programanalysis and the theory behind it can be found in [NNH99].

2.1 Program Analysis

The goal of a program analysis is to statically determine properties thathold for every possible execution of a given program. Since it is not pos-sible to simulate every situation that might occur during the execution ofa program, program analysis uses computable and safe approximations todescribe the dynamic behavior of a program. An approximation is consid-ered to be safe if and only if every possible program state is reflected in theanalysis results. If the analysis is not able to find out something about thedesired property, which means that everything is possible, this informationalso has to be present in the analysis result. This will sometimes result inover-approximation.

There are three main approaches to program analysis: data flow analysis,constraint based analysis and type based analysis. Data flow analyses requirethe control flow graph of the analyzed program and calculate the analysisinformation for every node in the graph. See the next section for a moredetailed description. A constraint based analysis constructs a system of setconstraints from a given program and then iteratively solves this system. Inthe basic approach, these systems do not make use of control flow informationfor the program, so the result is one solution of the system for the wholeanalyzed program. Type based analyses deduce the analysis informationfrom a set of inference rules. This works very similar to the type checking infunctional programming languages like SML.

Although all approaches in practice share many similarities, the focus of this

4

work will be on data flow analysis. It is thus closer looked at in the following.

2.2 Data Flow Analysis

A data flow analysis works on the control flow graph of a program, whichcontains a node for each statement. Edges in the graph represent the pos-sible control flow of the program. Hence there is an edge from one node toanother iff the statement corresponding to the second node can be executedimmediately after the statement corresponding to the first node.

Data flow analyses compute an analysis result for each program point (eachnode in the control flow graph). This works as follows: the informationthe analysis wants to compute is represented by a data structure called thecarrier. The carrier highly depends on the property that is analyzed. Fur-thermore, the analysis has to define a transfer function that models the effecta program statement has on the carrier. In other words, the transfer functiondescribes the operational semantics of a program with respect to the carrierof the analysis.

Function calls can be handled in several ways by a data flow analysis. Oneway is to construct an interprocedural control flow graph, where there areadditional edges for each function call from the call site of a function to thebeginning of the code for the function and from the end of the function tothe node after the function call. This has the effect that for each functioncall, the whole body of the function has to be re-analyzed.

Another way to handle function calls is the so called functional approach,which tries to calculate the effect of a function call on the carrier in order toreduce the number of times function bodies have to be re-analyzed.

To obtain a result, the analysis does a fixed point iteration on the controlflow graph. When doing a forward analysis, the graph is traversed in theorder of the actual control flow. During a backward analysis the order isreversed. In the beginning, some initial value is assigned to each node inthe graph. Afterwards, the analysis goes over the graph and applies thetransfer function to each node, combining the new result with the resultsfrom previous iterations. This is done until the result has stabilized for eachnode. The way the analysis selects nodes from the graph and combines oldinformation with new information has a great impact on the performance ofthe analysis.

The details of how to design a data flow analysis, in particular how to makeit terminating, efficient and correct (e.g. lattice theory and abstract inter-

5

pretation), have been omitted in this brief description. An in-depth study ofall the underlying theory can be found in [NNH99] or [WS07].

2.3 Related Work

Many papers on pointer analysis have already been published, but at leastfor the analysis of function pointers, existing algorithms leave some thingsto be desired. Partly this is due to the fact that most pointer analyses weredesigned to be used in compilers to discover data dependences in order to beable to apply optimizing program transformations.

Pointer analyses can be partitioned into three groups:

• An alias analysis computes pairs of expression which might or mustaccess the same memory location. This is the classical approach toresolve data dependences in a compiler.

• Points-to analyses calculate a points-to set for each pointer variable.The elements of this set represent the possible values of a pointer vari-able. However, although there are points-to analyses that try to handledata structures on the heap, generally they do not handle it very well.

• A shape analysis (e.g. [SRW02]) can not only be used to determine aliasrelations between memory locations, but it can also verify propertiesof data structures in memory, like the cyclicity of a list. Unlike theother analysis types, shape analyses are specifically designed to handledynamically allocated memory.

Since this work describes a points-to analysis, most of the algorithms thatare described below also fall into this category. An empirical study aboutmost of these analyses can be found in [HP00].

Existing points-to analyses can be divided into flow-sensitive analyses, whichuse the control flow of a program for the analysis, and flow-insensitive anal-yses, which look at the statements of a program without considering a possi-ble order of execution. However, there are also some hybrid approaches thatcombine both strategies.

The flow-insensitive analysis described by Steensgaard in [Ste96] calculatespoint-to sets by considering it as a typing problem. Shapiro and Horwitztried to improve this idea [SH97].

6

Another flow-insensitive approach is to construct a system of set constraintsover points-to sets and solve this system ([And94], [PKH07]).

Emami et al. presented a flow-sensitive analysis in [EGH94], which runs onthe control flow graph that computes alias pairs but uses function inliningfor every function call. If their analysis discovers a target for a call througha function pointer, the target function also gets inlined. This way, the con-trol flow graph grows during the analysis. Obviously, the analysis does notperform very well for large programs or those with recursive functions.

The algorithm published by Wilson and Lam in [WL95] calculates points-tosets with a data flow analysis that calculates the effect on the data flow valuefor every function call (functional approach).

Among several other analyses, one can find an analysis in [HBCC99] that isflow-insensitive for the intraprocedural part of the analysis and flow-sensitivefor the interprocedural part.

The application of pointer analysis to the construction of call graphs is stud-ied in [CmWH99] and [MRR04].

7

3 Analysis Description

A high-level description of a general pointer analysis for C programs that donot use dynamic memory allocation is presented in this chapter.

3.1 Overview

To determine the possible targets for a function call through a functionpointer in a given program, one needs to know all possible values this func-tion pointer might have during a run of the program. Like any other pointer,a function pointer is a variable that stores the address of a memory loca-tion. Therefore, if a program analysis can compute the possible values of allpointer variables, it is also possible to resolve all function pointer calls withthis information. Since C allows indirect memory access through pointers,any program analysis that wants to find out something about possible valuesof variables has to do some form of pointer or alias analysis anyway. So itseems quite natural to do a full pointer analysis on a program to resolve func-tion pointers. That is why this chapter describes a general pointer analysisthat will be used to implement the function pointer analysis described in thenext chapter.

The idea behind the presented analysis is to calculate a points-to mapping forvery program point of a given program using a data flow analysis. This map-ping assigns a set of memory location to every memory locations containinga pointer variable. Those sets are also called points-to sets in the following.If the mapping calculated by the analysis assigns a points-to set to somememory location, this means that this location might store the address ofthe locations in the set.

8

3.2 Memory Model

In order to store information about memory locations in the points-to map-ping, they have to be modelled in an abstract way. The approach chosen forthis work is to preserve information about the relative position of memorylocations that have to form consecutive blocks in memory during an actualexecution of the program (e.g. elements of arrays and structures), whereasthe model assumes nothing about the position of those blocks relative to eachother. This means any variable in a program, no matter if it is of a basic ora complex type, is treated as a completely independent object in memory.A consequence of this is that some forms of pointer arithmetic cannot beexpressed in this model, namely those that would leave the address rangeof some variable and enter that of another, as during an out-of-bound arrayaccess. Therefore this kind of operations are not allowed in the programsthat serve as input for the analysis described here, although they might havea well-defined semantics in the compiler a given program was written for.Nevertheless, this seems to be a sound restriction since such programs are ingeneral not portable because they use assumptions about the memory layoutthe target compiler generates.

The intuition behind the model used here is that memory accesses, examinedon a low-level, usually start from some base address (like the address where anarray or struct is located). They then move relative to this position, e.g. toselect some element from a structure or to iterate through an array by addinga constant or a variable value to the base address. Since the analysis is meantto be compiler and platform independent, it does not assume anything aboutthe absolute size of a variable. This is reasonable because a variable of typeint, for example, might occupy 2, 4, or 8 bytes in memory, depending onthe target architecture. The layout of structures in memory might also vary,depending on the padding used by the compiler. Therefore, parts of a largerdata structure are described relative to the parent object. The idea behindthis is that arrays always consist of elements of the same size and the positionof an element within an array or struct never changes. So it is completelysound to just number the subobjects and refer to them via this numbering.

A memory location is described as a list of so called offsets. Those listsare constructed from the expressions in the program that might access thelocation. To do this, an offset, which is either a unique name or an integerconstant, is assigned to each identifier in the expression. Then the offset listfor the expression is calculated in a bottom-up fashion from the syntax treeof the expression. Offsets are assigned to identifiers as follows: variable andfunction names are mapped to themselves, whereas identifiers for structure

9

elements are mapped to their relative position in the structure, but withoutconsidering their size. To make this mapping work, all identifiers in ananalyzed program have to be unique. From now on, it will be assumed thatthis holds for all input programs of the analysis. In an actual implementation,this can be achieved by an additional preprocessing phase of the analysis.

So, for simple expressions that only consist of a variable name, the offset listthat is assigned to it only contains the variable name itself. The offset listthat is assigned to an array index expression with a constant value is the listthat only contains this constant value and therefore describes the relativeposition of this element within the array. Variables within an array indexexpression cannot be evaluated statically, because their value is not knownin general. This is why the offset list describing such a subexpression onlycontains the unknown offset ⊤. A memory access with unknown offset ismeant to span the whole parent data structure.

To get the offset list for more complex expressions, the offset lists of thesubexpressions are concatenated. With this construction, it is possible todescribe the memory locations which can be accessed by expressions thatdo not use any indirection through pointers. The construction of offset listsfrom expressions is shown in Figure 3.

Since an offset list only describes one consecutive block of memory, as soon asthere are pointers involved it is not enough to describe the memory locationsan expression might access. This is why points-to sets will be assigned toexpressions instead of offset lists in the following. A points-to set is nothingbut a set of offset lists, so for simple expressions the points-to set is just thesingleton set containing the offset list described above. With the points-tomapping described in the next section, it is also possible to describe the mem-ory locations that might be accessed by an expression containing a pointerdereference. The points-to sets of such expressions are not necessarily sin-gletons, of course.

3.3 Points-to Mapping

The points-to mapping is a partial function that maps memory locations topoints-to sets. In other words, it stores possible values for pointer variables,which is exactly what the analysis described in this document is meant tocalculate.

The data structure that was chosen for the points-to mapping in the actualimplementation is a recursive hash table. Basic variables like pointers or

10

s t r u c t{

i n t ∗p1 ;i n t ∗p2 ;

} s1 ;

s t r u c t{

char c :i n t a [ 4 ] ;

} s2 ;

i n t ∗ ar r [ 1 0 ] ;i n t ∗p ;

Identifier Offsetp1 0p2 1s1 s1

c 0a 1s2 s2

arr arrp p

Expression Offset lists1.p1 [s1, 0]s1.p2 [s1, 1]s1 [s1]

s2.c [s2, 0]s2.a [s2, 1]s2.a[1] [s2, 1, 1]s2.a[s2.c] [s2, 1, ⊤]

Figure 3: Use of offsets to model memory locations

integers are mapped directly to a points-to set, whereas variables that areof an array or structure type are mapped to another hash table. Since theC standard allows conversion between pointer and integer variables ([C99],page 47), there is no real distinction between pointers and other variablesthat are large enough to store an address. To look up the points-to set fora given memory location, the concept of offset lists from the last section isused. Starting from the top-level points-to mapping, one has to check whatis mapped to the head of the offset list in the mapping. If it is a points-toset, the process is finished, otherwise one has to continue with the tail of theoffset list and the points-to mapping that was the result of the earlier lookup.

The points-to mapping can also be thought of as a tree. The leafs of the treestore the points-to sets and all edges are labeled with offsets. When lookingup the points-to set for a memory location, the tree is traversed from theroot along the edges which match the offsets in the offset list for the memorylocation.

To easily lookup points-to sets for arrays of pointers that are indexed with avariable, an entry for the unknown offset ⊤ is also stored for each of the map-pings that are used to model array and struct variables. What is mappedto the unknown offset is a safe approximation of all entries stored in themapping, so in general the set union of all points-to sets that are stored inthe mapping. A pointer that has not been initialized is mapped to the emptypoints-to set, which is represented by ⊥. Pointers that potentially point toany memory location are mapped to ⊤. This describes the points-to setwhich contains any possible list of offsets.

11

s t r u c t{

i n t ∗x ;i n t ∗y ;

} s ;

i n t a [ 1 0 ] ;i n t ∗z ;

i n t func t i on ( bool f l a g ){

s . x = &a [ 1 ] ;s . y = &a [ 2 ] ;

// do something with a

i f ( f l a g )z = s . x ;

e l s ez = s . y ;

r e turn ∗z ;}

Figure 4: Example source code

An example of how the information computed by the analysis looks likeis displayed in figure 5. It shows the control flow graph of the programpresented in figure 4 and the calculated points-to mappings. The mappingwhich is valid after a program point is annotated at the edges leaving therespective node in the graph.

3.4 Updating the Points-to Mapping

During the transfer function of the analysis, two things have to be computedsimultaneously when updating the points-to mapping:

• the memory locations which might be accessed by a given expression

• the points-to set of a given memory location

Both can be represented by a points-to set, but it is important to under-stand the difference. For a simple expression without some form of pointerdereference, the memory locations it might access can be derived directly byconstructing its offset list and hence the points-to set representing the mem-ory locations the expression can access would be a singleton. For expressionsthat employ indirection, this does not hold and therefore sets are required.

12

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 5: Control flow graph for code from figure 4 with analysis results

On the other hand, a points-to set describes the contents of a pointer variablewhich is the address of a memory location.

Intuitively, the memory locations which can be accessed by an expressiondescribe the locations that will be used for read/write access, whereas thepoints-to set which is assigned to a memory location in the points-to mappingdescribes what is currently stored in these locations.

3.4.1 Assignments

Nodes in the control flow graph which contain an assignment expressionmodify the contents of the points-to mapping if it is an assignment betweenmemory location whose content might be a memory address. To capture the

13

effect of an assignment like

a = b

where a and b represent arbitrary expressions, the first thing the analysis hasto do is calculate the offset lists which describe the memory locations thatcan be accessed by the left and the right hand side of the assignment. Sincea and b are arbitrary expressions, the memory location they describe mightnot be unique. For all memory locations described by the right-hand side ofthe assignment, the analysis looks up what is stored for those locations in thepoints-to mapping and builds the union of the results from these lookups.This new set has to be stored in the points-to mapping for the memorylocations described by a. The intuition behind this is that if b stores anaddress, a stores the same address after the assignment.

As already stated, a might not describe one unique memory location. Thiscan happen when a subexpression of a contains a dereference of a pointerwhose points-to set is not a singleton or accesses an array with an indexthat is not known statically. In order to safely approximate the result of theassignment in this case, the information which is already stored in the points-to mapping for the left-hand side of the assignment must not be overwritten.Therefore the points-to set is updated with the union of the already storedpoints-to set and the newly calculated set from the right-hand side. This iscalled a weak update because it does not remove any previous informationand only makes the points-to set grow.

On the other hand, if a describes a unique memory location, the assignmentis guaranteed to write to this memory location. Therefore all informationstored in the points-to mapping for this location can be safely replaced bythe new information. Thus it is possible to do a strong update in the map-ping and only store the newly calculated set as points-to information for thelocation described by a. It is desirable to do strong updates whenever possi-ble because they can produce smaller points-to sets and hence provide moreprecise information.

Updating the points-to mapping happens by evaluating expressions in abottom-up fashion. So in the example above, the expressions a and b areevaluated before the assignment is evaluated by the analysis. The evaluationof subexpression in turn might modify the points-to mapping. This recursivestrategy takes care of modeling side effects and indirect memory accesses inan easy way.

14

A special case that has to be considered when updating the points-to mappingis that a pointer to an aggregate object and a pointer to the first element ofthe object describe the same memory location ([C99], page 47). The analysishandles this by directly updating the zero element of the points-to mappingfor the aggregate object in this case, e.g. if an array is just dereferencedinstead of using the subscript operator [] with index 0.

3.4.2 Address-of Operator

The use of the address-of operator & is the operation which is mainly usedto access the address of a variable instead of its value. Other methods forthis, like direct assignments of an array variable or a function to a pointervariable, can be reduced to an expression that uses the address-of operatoror might be handled as a special case in an actual implementation of theanalysis.

An application of the address-of operator is usually encountered during theevaluation of an assignment when the analysis tries to calculate the memorylocation described by the right-hand side of an assignment. To model thememory location described by an expression of the form

&e

a temporary variable is added to the points-to mapping. The temporary ismapped to the memory locations that can be accessed through e. In fact,this is a direct translation of the semantics of the address-of operator to theanalysis, although the introduction of a temporary variable might seem oddat first. During a further evaluation of an expression like

p = &e

the lookup in the points-to mapping for the right-hand side of the assignmentwill yield the memory locations which can be accessed by e. So, assuming p

and e are simple variables, p will point to e in the mapping and the temporaryvariable can be discarded afterwards.

3.4.3 Pointer Dereference

In order to determine which memory locations might be accessed by a pointerdereference expression, the information stored in the points-to mapping hasto be used. So to handle the expression

15

*p

whereas p might be an arbitrary complex expression, the analysis has todetermine which memory locations can be accessed by p and then look upthe points-to sets stored in the points-to mapping for all of those locations.The union of all these sets describes the memory locations which might beaccessed by the dereference expression.

3.5 Language Constructs requiring special handling

3.5.1 Pointer Arithmetic

The memory addresses stored in pointers can be manipulated directly withpointer arithmetic, but this operation is only well defined for pointers toelements of an array ([C99], page 83). Principally adding n to a pointer tothe mth element of an array yields the (n + m)th element, subtraction isdefined similarly.

Since the offsets which are used to describe the elements of an array storethe relative position in the array and not the absolute size, it is fairly easy tomodel the effect of an arithmetic operation on the points-to set of a pointerby just adding the integer operand to the last entry of each offset list inthe points-to set. If the actual value of the integer operand is not knownstatically, the result of the addition is not known statically either and hencewill result in the unknown offset. This approach works very nicely for stan-dard applications of pointer arithmetic, e.g. iterating through an array bypointer arithmetic, but there are special cases like casting of pointers to arrayelements and multidimensional arrays that require special handling.

3.5.2 Casting

Casting pointers might modify the size of the base type of a pointer. If apointer is casted to a pointer with a smaller base type, pointer arithmeticand the dereference operator still can be applied to the pointer of the smallerbase type. Hence it is possible to write data to subparts of the objects theoriginal pointer pointed to, e.g. it is possible to access the elements of anarray of pointers bitwise by casting a pointer to an element to a pointer tochar. This has to be considered when updating points-to sets. Neverthelessit must be possible to cast back and forth between different pointer typeswithout information loss as long as no pointer arithmetic is used.

16

The solution that was chosen for the presented analysis was to add a castingtag to points-to sets which are copied between pointers of different base typesizes. If pointer arithmetic is applied to a points-to set with this tag, theresult is undefined (⊤). All other operations on sets with this tag work asthey do on sets without it.

3.5.3 Multidimensional Arrays

In C it is possible to construct multidimensional arrays, which are basicallyarrays whose elements are arrays again. Pointer arithmetic on pointers intomultidimensional arrays is different from pointer arithmetic on pointers intosimple arrays. For simple arrays, the pointer is not allowed to leave the arraybounds, at least if it is used for a dereference operation, and the definitionabove implicitly assumes this. On the other hand, it is quite common touse one single pointer to iterate through all elements of a multidimensionalarray. Since the analysis uses recursive points-to mappings to model multidi-mensional arrays, using the definition for simple arrays would result in onlyiterating over the first subarray. To make this work for multidimensionalarrays, too, the analysis must detect whenever the address of an element ofa multidimensional array is taken. In this case, the offsets used for indexinginto the array are modified to ⊤ for all offset lists in the points-to set of thepointer, making the pointer cover the whole multidimensional array. As aresult of this, when the analysis evaluates pointer arithmetic there is no needfor a special handling of pointers into multidimensional arrays. Nonetheless,standard operations (like assignments to elements) on multidimensional ar-rays can be represented in a precise way by calculating the offset lists asusual for expressions which do not involve pointers.

3.5.4 Unions

Unions in C offer a possibility to store many different types in the samememory block. This has to be considered by a pointer analysis because insome cases it is allowed to read data from the elements of one type that hasbeen written there through the elements of another type. An example forthis is provided in figure 6. Although this is only allowed for structures in theunion that declare elements of the same type at the beginning ([C99], page73), assuming that elements of the union are accessed only through theirrespective selector might yield wrong results. Hence it would be incorrect totreat a union like a struct variable.

17

union {s t r u c t {

void (∗ ca l l b a ck ) ( i n t ) ;char data [ 1 0 ] ;

} s1 ;

s t r u c t {void (∗ ca l l b a ck ) ( i n t ) ;i n t id ;

} s2 ;} u ;

u . s1 . c a l l b a ck = foo ;u . s2 . id = 1 ;

u . s2 . c a l l b a ck (u . s2 . id ) ;

Figure 6: Valid use of a union containing structures

Again, the description of memory locations by offset lists offers a very elegantsolution to this problem. Since the elements of structures in the union thatcoincide must have the same size and ordering, their offset will be the same.That is why it is possible to discard the selector of the union elements fromthe offset list, which basically lets everything contained in the union overlap.Nevertheless, this is completely safe because for elements where mixed accessto the union elements is allowed, this will provide correct result. For otheraccesses, the semantics of the input program for the analysis would not bewell-defined, so the output of the analysis also does not have be.

To further illustrate how the analysis handles unions, with the definition fromfigure 6, the offset list for the expressions u.s1.callback and u.s2.callback

both will be [u, 0]. So in the memory model of the analysis both expres-sions will access the same memory location, which is exactly what wouldhappen during an actual execution of the program.

18

4 Implementation

The analysis described in the last section was implemented using an existingtoolchain for generating static program analyzers for C programs. In addi-tion to what was described in the last chapter, several other tasks had tobe handled by the actual implementation, namely the generation of uniqueidentifier names in the analyzed program and the construction of a mappingfrom those names to the offsets used by the analysis. It is also necessary toextend the control flow graph of the analyzed program during the analysisas targets for calls through function pointers are found by the analysis. Fur-thermore, the implementation offers the possibility to only consider nodes ofthe control flow graph that have an effect on function pointer variables or toresolve function pointers in an optimistic way.

The output of the analysis implementation is a complete control flow graphof the analyzed C program, at least if all function pointers could be resolved.This CFG can be reused by other analyses that are implemented in thesame framework. Furthermore, the analysis implementation can create anannotation file for the AbsInt aiT Worst Case Execution Time Analyzer.For each position in the analyzed source code that is a function pointer call,this file stores which functions might be called at this program point. Thisprovides aiT with the necessary information to compute the CFG for thecompiled version of the program on assembly level, which is required to dothe worst case execution time analysis.

4.1 Implementation Framework

4.1.1 Program Analyzer Generator (PAG)

The Program Analyzer Generator ([PAG]) is a tool to automatically gen-erate data flow analyzers from a specification in a functional programminglanguage. It was originally developed at Saarland University and is now

19

maintained by AbsInt Angewandte Informatik GmbH. The process of devel-oping a data flow analysis is greatly simplified by PAG, because it providesmeans to easily implement the domain of an analysis, iterate the control flowgraph of the analyzed program and it takes care of the fixed point computa-tion. For each programming language one wants to generate analyzers for, itis necessary to implement a front-end for PAG that is responsible for parsingprograms and generating their control flow graph as well as supplying aninterface to access it.

The specification of an analysis is translated to C source code by PAG. Itis also possible to directly implement parts of an analysis in C instead ofgenerating it. The actual analyzer is created by compiling the generatedcode with the front-end for the analyzed language.

4.1.2 ROSE Compiler Infrastructure

The ROSE compiler framework ([ROS]) is a source-to-source infrastructurewhich has been developed at the Lawrence Livermore National Laboratory(LLNL). ROSE offers an easy way to parse C/C++ programs and access theirabstract syntax tree (AST), e.g. for program analysis or program transfor-mations. Like a traditional compiler, ROSE is divided into a front-end, amid-end and a back-end. The Edison Design Group ([EDG]) front-end isused by ROSE to parse C/C++ programs, but the internal representationof the EDG front-end, which is C-style, is translated to an object-orientedrepresentation of the AST on which ROSE works internally. The mid-endallows modifications of the AST in an easy fashion. The neat thing aboutthe approach chosen by ROSE is that program transformations of C/C++programs can be specified in C++ directly, so it is not necessary to learn aspecial transformation language to work with ROSE. Moreover, ROSE pro-vides a back-end that can unparse the AST back to C/C++. That is whyeverything that was present in the original source code has to be representedin the AST, even whitespace or comments.

ROSE is not limited to C/C++, Fortran for example is also supported, butsince only C is considered here, the other parts are of no interest for this work.Nevertheless, ROSE offers many interesting possibilities which go beyondwhat it is used for in the implementation of this function pointer analysis.

20

��

��

��

��

��

��

��

��!�!��!��

��"��

��#��"

��

��"��

��$��

��"� ��

��%

��

��

��

��#��"

��#��"%

Figure 7: SATIrE Implementation overview from [Sch07]

4.1.3 Static Analysis Tool Integration Engine (SATIrE)

The Static Analysis Tool Integration Engine (SATIrE) is an architecture tocombine different program analysis and transformation tools ([Sch07]) forthe usage with C and C++ programs. It is being developed at the ViennaUniversity of Technology and it heavily relies on the ROSE infrastructure.

The combination of various independent analysis techniques is achieved bytransforming input programs to a common intermediate representation (IR).The input program might already contain annotations of analysis results fromprevious runs of different analyses which are also represented in the high-levelIR. For each integrated tool, the high-level IR must be translated to the tool-specific intermediate representation before the tool can start working on theprogram. After a successful run, the tool-specific IR can be translated backto the common IR, which can also store the results of the run. The use of theROSE back-end also allows it to translate the high-level IR back to sourcecode. It is thereby possible to annotate analysis results directly to the sourcecode of the analyzed programs. Figure 7 gives an overview of the currentimplementation of the SATIrE architecture.

Although SATIrE can be used for other things (like it is possible to translateC/C++ to a Prolog representation, work with the Prolog term and then

21

translate it back to C/C++ source code), for this work SATIrE only servesas front-end for an analysis generated with PAG. In this role, SATIrE usesROSE to get the AST for the program that is meant to be analyzed andtranslates the AST to an interprocedural control flow graph that can beaccessed by PAG. This involves some non-trivial program transformationbecause some basic operations of C, like parameter passing, are not directlysupported by PAG. These transformations are also achieved by using theROSE infrastructure.

4.2 Required Extensions

4.2.1 Variable Renaming

The general pointer analysis described in chapter 3 requires the possibilityto assign a non-ambiguous offset to each identifier in the analyzed program.Since identifiers are not guaranteed to be unique, some form of variable re-naming has to be done before the analysis can start. Although SATIrE offersthe possibility to number identifiers in a program according to their scope, sothat variables with the same name but a different scope can be distinguished,this is not good enough to construct the offset mapping for the analysis.This is the case because names of struct and union elements have to bedistinguished from ordinary variable names. Therefore a renaming phase wasadded to the analysis implementation before the control flow graph is con-structed from the ROSE AST. This phase not only generates a unique namefor each identifier in the analyzed program, but it also calculates a mappingthat assigns an offset to those unique identifiers. Since this mapping is calcu-lated in advance, the analysis can just use it when constructing offset lists forexpressions during calculations in the transfer function. Fortunately, ROSEmakes variable renaming and constructing the offset mapping relatively un-problematic because it provides an easy to use interface to traverse the ASTand match certain language constructs.

4.2.2 Control Flow Graph Refinement

Without doing a function pointer analysis, the control flow graph of a pro-gram that uses function pointers must be incomplete because the functionsthat are called by a call through a function pointer are not known. Thereforethe control flow graph, as it is generated by SATIrE for such programs, lacksthe call and return edges for those call sites in the program. This is prob-

22

lematic because a data flow analysis on an incomplete CFG might produceincorrect results because it misses realizable control flow paths. So obviouslyit is necessary to add the appropriate call and return edges to the controlflow graph whenever the analysis discovers a target for a function pointercall. Since modification of the CFG is not supported by PAG during theanalysis, the approach that was chosen for the implementation is to let theanalysis run to completion on the incomplete graph. Afterwards the call andreturn edges are added for those functions that are in the points-to set of theexpressions that form a function pointer call and the analysis is restarted.This process is repeated until no new targets are found.

The stepwise extension of the CFG might add too many call and return edgesbecause the analysis information at a function pointer call site can changefrom one iteration of the analysis to another. This is very unlikely though,because it would require that the value of a function pointer is changed in afunction that is called through a function pointer, and even then the edgesare never removed. Nevertheless the results of the analysis are still sound,although they might be less precise. Additional edges in the CFG only meanthat more unrealizable paths are considered by the analysis, but unrealizablepaths might be there anyway because of the approximative nature of dataflow analysis. In the final iteration of the analysis no new targets have beenfound. Hence, the CFG the analysis works with is a superset of the minimalcorrect CFG of the analyzed program if and only if all function pointer callscould be resolved in previous iterations. Therefore the analysis results arecorrect, if it was possible to find a target for each function pointer call site.Otherwise the current CFG might still be a subset of the actual CFG andthus the analysis results are not guaranteed to be correct.

4.2.3 External Functions

Quite often it is not possible to analyze all functions that are called by aprogram because their source code is not available. This happens almost ex-clusively for functions from program libraries. In many cases, these functionswill not affect the information calculated by the pointer analysis. Neverthe-less this is possible and must be considered to get correct results. Thereforethe option was added to annotate the effect an external function has on thepoints-to information, of which there are three possible:

• None, which means the external function call does not influence anypointers of the program.

23

• Local destructive, which has the effect that after the call the returnvalue and all memory locations reachable through the arguments ofthe function are assigned to ⊤ in the points-to mapping.

• Global destructive, meaning that all information gathered so far be-comes invalid after the function call.

The annotations are stored independently from the analyzed program andhence must be provided only once for each library used by any number ofanalyzed programs.

4.3 Further Extensions

4.3.1 Program Slicing

To improve the run-time of the function pointer analysis, an additional anal-ysis phase was added that determines at which program points the values offunction pointers might be modified directly or through aliases. In the actualpointer analysis, the transfer function is only applied to those nodes.

The preprocessing analysis to determine nodes in the CFG that are interest-ing for the function pointer analysis works by looking for interesting iden-tifiers in the expressions of a program. In principal this works by doing abackward data flow analysis which applies the following rules to the CFGuntil a fixed point is reached:

• all identifiers in an expression that is a function pointer call are inter-esting

• an identifier is interesting if it occurs within an expression that containsan identifier which is known to be interesting

• a node in the CFG which contains an expression with an interestingidentifier is interesting

Nodes in the CFG are only marked instead of actually removing nodes fromthe graph because with this approach it is possible to reuse the CFG forother analyses without recalculating it. This way, despite slicing, it is stillpossible to let subsequent analyses work with the complete CFG createdby the function pointer analysis. An exhaustive overview of the differentanalysis stages is shown in figure 8.

24

��

��

��

��

��

��

Figure 8: Analysis stages

4.3.2 Optimistic Analysis

If a completely safe pointer analysis reaches a program point at which a valueis assigned to a memory location the analysis does not know, it must discardall information it has gathered so far. This is due to the fact that suchan assignment could change the content of any memory cell and thereforenone of the calculated points-to sets can be guaranteed to be safe. This casemight occur for various reasons, e.g. because a pointer is dereferenced thatwas manipulated by a complicated form of pointer arithmetic or an arrayof pointers is indexed with a variable but only some of the pointers wereinitialized previously.

Such effects might influence the analysis results quite considerably, especiallywhen global arrays of function pointers are used. That is why an optionaloptimistic mode was added to the analysis, which differs in the followingpoints from the standard analysis:

• For global variables that are declared with an initializer, each time theanalysis enters a function body it checks if this information has beenoverwritten with ⊤. In this case, the information from the initializer isadded to the points-to mapping again.

• The unknown offset in a points-to mapping for an array or a struct

variable is never mapped to ⊤. Instead, the points-to set of the un-known offset only collects entries of the points-to set for the otherentries in the mapping which are not mapped to ⊤. This makes itpossible to handle arrays of pointers in which some of the entries areset to NULL.

• When resolving targets of calls through function pointers, the analysisalso uses targets which occur while the analysis is still running and

25

the fixed point has not yet been reached. Also when looking up whatis stored in the points-to mapping for the points-to set of a functionpointer call expression, the information stored for the unknown offsetsis used if the exact items in the offset list are mapped to ⊤.

Obviously this approach is not guaranteed to provide correct results in gen-eral. Nonetheless, under the restriction that no complicated pointer arith-metic is used to modify function pointer variables and uninitialized memoryis never used, this optimistic strategy seems to work quite well in practice.

26

5 Results

The analysis implementation was tested with a set of programs that use func-tion pointers and whose source code is publicly available. All programs wereanalyzed with the different analysis modes offered by the implementation.The test programs and the analysis results are presented and evaluated inthe following sections. Some basic information about the test programs andthe results for the standard analysis mode which does not use any optimisticassumptions can be found in figure 9. The results for the various other anal-ysis modes are displayed in figure 10. Columns labeled Resolved contain thenumber of function pointer calls for which the analysis was able to determinewhich functions are called. The Targets column lists the average size of thepoints-to set of a function pointer used for a call.

5.1 Test Programs

5.1.1 grep

The well-known Unix tool grep uses function pointers in a way that showsthe advantages the analysis described in this work offers compared to other

Characteristics Standard ResultsVersion Lines Ind. Calls Resolved Targets

diction 0.7 2037 3 0 0grep 2.0 12417 3 0 0gzip 1.2.4 8163 4 1 1sim6890 0.1 3290 97 2 6

Figure 9: Analysis results for the test suite using the standard mode of theanalysis implementation

27

Optimistic Results Slicing Results Optimistic + SlicingResolved Targets Resolved Targets Resolved Targets

diction 1 1 3 1 3 1grep 2 12.5 0 0 3 9gzip 1 1 2 1 4 3.5sim6890 97 10 2 6 97 10

Figure 10: Analysis results for the test suite using the slicing and optimisticmode of the analysis implementation

analyses, but also illustrates the problems these kind of analyses have tohandle when they are applied to real-world programs.

The modes of operation that are offered by grep are stored in a global arrayof structures which contains function pointers to the functions that are appro-priate for the respective mode. According to the mode that is selected at thestartup of the program, global function pointers that determine the behaviorof grep are set during the initialization phase in the function setmatcher().The parts of the grep source code responsible for this are shown in figure 11.

Since the global function pointer variables are initialized from distinct struc-ture elements within the global array of structures, an analysis that doesnot compute points-to information for the elements of objects that have anaggregate type will calculate points-to sets that are too large. In this case,this would result in equal points-to sets for the global variables compile andexecute. Hence, this would result in an interprocedural control flow graphwhich is too large if this information was used to add edges for functionpointer calls to the graph.

On the other hand, the use of a recursive points-to mapping to store thepoints-to information for objects that have an aggregate type can handle thisapplication of function pointers. What is problematic is that the initializa-tion of the global variables takes place within a loop. Since we know nothingabout the loop bounds statically, it has to be assumed that every element ofthe array can be accessed, including the last element which is initialized withzeroes in this example. As a pointer with value zero has no well-defined tar-get, the analysis conservatively assumes that the target might be anything.Hence the calls through the pointers compile and execute (which are omit-ted in figure 11) can not be resolved by the analysis implementation, at leastnot in its standard mode. Nevertheless, the optimistic modes of the analysisdescribed in section 4.3 can resolve these calls because it assumes that the

28

/∗ grep . h ∗/extern s t r u c t matcher{

char ∗name ;void (∗ compi le ) ( char ∗ , s i z e t ) ;char ∗(∗ execute ) ( char ∗ , s i z e t , char ∗∗ ) ;

} matchers [ ] = {{ ” d e f au l t ” , Gcompile , EGexecute } ,{ ” grep ” , Gcompile , EGexecute } ,{ ” ggrep ” , Gcompile , EGexecute } ,{ ” egrep ” , Ecompile , EGexecute } ,{ ”posix−egrep ” , Ecompile , EGexecute } ,{ ” gegrep ” , Ecompile , EGexecute } ,{ ” fg r ep ” , Fcompile , Fexecute } ,{ ” g fg r ep ” , Fcompile , Fexecute } ,{ 0 , 0 , 0 } ,

} ;. . .

/∗ grep . c ∗/s t a t i c void (∗ compi le ) ( ) ;s t a t i c char ∗(∗ execute ) ( ) ;

i n t setmatcher ( char ∗name){

i n t i ;

f o r ( i = 0 ; matchers [ i ] . name ; ++i )i f ( strcmp (name , matchers [ i ] . name) == 0)

{compi le = matchers [ i ] . compi le ;execute = matchers [ i ] . execute ;r e turn 1 ;

}r e turn 0 ;

}. . .

Figure 11: Parts of the grep source code

accesses within the array only go to elements that store valid information.For the example shown, this is completely safe.

5.1.2 diction

GNU diction offers two command line tools, diction and style, that cancheck text files for diction and language style. These programs share partsof their source code. The use of a function pointer occurs for the call ofa function that is responsible for parsing sentences in the input file. Theparameters of the function contain a function pointer to the function thatis responsible to do the actual processing of the sentence. For diction,

29

this pointer always stores the address of a single function. The analysisimplementation is able to detect this and hence can construct the completeand minimal interprocedural control flow graph for diction.

5.1.3 gzip

The file compression tool gzip uses a global function pointer variable todecide how input files are processed, meaning which compression algorithm isused. The initialization and the application of this function pointer take placein different functions called by the main function of the program. Thereforethe results of the analysis in figure 9 seem to be quite imprecise as the analysisis not able to resolve all of the function pointer calls. The explanation for thisis that grep makes use of Unix signal handlers. Hence the analysis assumesthat the values of the function pointers might be changed at any time by thesignal handlers and therefore cannot resolve the function pointer calls. Inspite of that the function pointer can be resolved if the analysis uses someoptimistic assumptions.

5.1.4 sim6809

sim6809 is a simulator for the Motorola 6809 microprocessor developed byJerome Thoen ([Tho98]). A large array of function pointers is used in thissimulator to select the function which is used to simulate the current instruc-tion by (almost) directly indexing into this array with the numeric value ofthe instruction. As the binary representation of 6809 instruction set doesnot seem to be dense, this array contains many entries with value zero andhence the same problems as for the analysis of grep arise. Nevertheless theanalysis implementation is able to resolve the calls under the assumptionsthat those NULL pointers are never used for a call.

5.1.5 Automotive software

An attempt was made to test the implementation with several large real-world automotive software projects, but this was not successful for severalreasons. At first, it is not trivial to analyze large pieces of software at all sincethe analysis framework has to access the whole source code at once. Thisrequires manual examination of the project hierarchy because the source codeis usually spread over several directories and existing project management

30

files (e.g. makefiles) cannot be reused for the analysis because those existingfiles are mostly used to compile only parts of the whole project.

Another problem that occurred was that some of the programs used speciallanguage keywords because they were developed using compilers for targetarchitectures with a small word size, but these keywords were not recognizedby the analysis framework. These problems could by solved with manualintervention, too.

Currently the analysis framework also still seems to have problems with someconstructs of the C programming language (e.g. valid source lets it crash).Understanding these crashes is extremely difficult because there is no preciseerror message, only the information that something is wrong in the abstractsyntax tree. Hence it is just not feasible for larger programs to manuallymodify the pieces of code that are responsible for the crash because it isimpossible to find them. For this reason it was not possible to apply theanalysis to real automotive code, although it was available.

5.2 Evaluation

The results of the application of the analysis to real-world programs seemdisappointing at first because the analysis is not able to resolve a significantnumber of function pointer calls without further assumptions. On the otherhand, the results that were achieved using the optimistic extensions to theanalysis described in section 4.3 are very good. A manual inspection of thetest programs convey the impression that these results are pretty close to anoptimal solution, although this cannot be guaranteed in general. Nonetheless,the slightly optimistic approach seems sufficient from a practical point ofview because there is just no rational reason to modify the values of functionpointers with complicated operations like excessive pointer arithmetic. Forthe construction of a complete control flow graph, or at least a more precisegraph than one that discards all function pointer calls, it does not seemrelevant that there might be the possibility that a function pointer with valuezero might be used for a call. This is a matter of program correctness whichis not the primary focus of this analysis. Hence the standard version is tooconservative to provide usable information, while the optimistic assumptionsare weak enough to hold for real-world programs.

Using a recursive points-to mapping to model the contents of aggregate ob-jects in memory provides more precise results than a model that does notconsider the subelements of complex data structures. The additional expres-siveness of this model in relation to previous works is depicted in figure 12

31

�

� �

� �

�

�

�

��

� � �

�

��

Figure 12: Better precision compared to other analysesa) Aggregate objects treated like basic objectsb) Only calculate points-to sets for struct (e.g. like [PKH07])c) Recursive points-to mapping

using the source code example from figure 4. This approach might be usefulfor other analyses as well, for example a flow-insensitive pointer analysis.

Flow-insensitive analyses are used more often in the literature and the resultspresented here seem to support the view that this method is sufficient. Thereason for this seems to be that a flow-insensitive analysis can be conservativewithout too much loss of precision because it is less precise than a flow-sensitive analysis in the first place. The effect of the conservative approachon the precision of the result is much bigger in the flow-sensitive case becausea flow-sensitive analysis must discard all its information whenever there is amemory access that cannot be resolved. Hence the flow-sensitive approachseems to deliver less precise results for a pointer analysis in practice althoughone would expect the opposite.

In its current state, the framework used for the analysis implementationmakes it rather difficult to analyze programs without user intervention. Thatis why it does not seem feasible at the moment to use the analysis for theautomatic extension of control flow graphs for programs or the automaticcreation of annotations for analysis tools that do not depend on the sourcecode because an user action would be required anyway.

32

6 Conclusion

6.1 Summary

This work described a flow-sensitive function pointer analysis for C programs.The intended area of application for this analysis is automotive software.This kind of software makes extensive use of function pointers but rarely usesdynamic memory allocation. Therefore the analysis was designed to deriveas much information as possible about function pointers on the stack withoutconsidering the possibilities and problems that can arise when dynamicallyallocated memory is used.

The new concept presented in this thesis is the use of a recursive points-tomapping to store the calculated information about pointers. This approachmakes it possible to model the contents of the stack in a precise abstract way.It is an extension of the ideas used in [WL95] but it is more precise and lessplatform dependent.

Results for the application of the analysis to real-world programs are twofold.Storing pointer information in a recursive mapping seems to be a very goodmethod to store precise information very easily. On the other hand, theexisting implementation of the analysis does not provide sufficiently preciseresults without further optimistic assumptions about the analyzed programs.Furthermore, the framework used for the implementation is not yet able tohandle all realistic C programs. Nonetheless the results are promising and itis probably not too hard to solve the remaining problems.

6.2 Outlook

An implementation of the analysis would probably be able to calculate muchbetter information about array elements if more precise information aboutaccesses to the elements were available. It thus seems like a natural extensionto place some form of constant propagation or interval analysis in front of the

33

pointer analysis to calculate information about the values of integer variablesand use this knowledge to evaluate index expressions of arrays more precisely.As the results of the pointer analysis might affect the results of the valueanalysis, one would have to iterate this process until the result stabilizes.

The results that were achieved with the analysis implementation indicate thatsome optimistic assumptions are necessary to get useful results. In its currentstate these assumptions are not optimal because they are not guaranteed tohold in any case. Further research into this direction could provide betteror safer results, e.g. by adding additional analyses to guarantee that thingsthat are assumed not to happen really never happen.

Modelling points-to information with a recursive mapping and the descriptionof memory locations with an offset list offers an advantage over the methodsthat have been used so far. The application of these methods to existingflow-insensitive pointer analyses might improve the results of these analysesconsiderably and therefore should be investigated.

Only simple forms of dynamic memory allocation can be handled by thepresented analysis because it was designed for programs that do not use dy-namically allocated memory. The use of cyclic data structures might even-tually cause divergence of the analysis. It would be a valuable extension tothe analysis if it was possible to analyze function pointers in dynamic datastructures or at least detect and avoid a possible divergence.

34

References

[And94] L. O. Andersen. Program Analysis and Specialization for theC Programming Language. PhD thesis, DIKU, University ofCopenhagen, May 1994. (DIKU report 94/19).

[C99] C99. JTC 1/SC 22/WG 14 - ISO/IEC 9899:1999 - ProgrammingLanguages - C. American National Standards Institute, 11 West42nd Street, New York, New York 10036.

[CmWH99] Ben-Chung Cheng and Wen mei W. Hwu. An empirical studyof function pointers using SPEC benchmarks. In Languages andCompilers for Parallel Computing, pages 490–493, 1999.

[EDG] Edison design group. http://www.edg.com.

[EGH94] Maryam Emami, Rakesh Ghiya, and Laurie J. Hendren.Context-sensitive interprocedural points-to analysis in the pres-ence of function pointers. In SIGPLAN Conference on Pro-gramming Language Design and Implementation, pages 242–256,1994.

[HBCC99] Michael Hind, Michael Burke, Paul Carini, and Jong-Deok Choi.Interprocedural pointer alias analysis. ACM Transactions onProgramming Languages and Systems, 21(4):848–894, 1999.

[HP00] Michael Hind and Anthony Pioli. Which pointer analysis shouldI use? In International Symposium on Software Testing andAnalysis, pages 113–123, 2000.

[Lan92] William Landi. Undecidability of static analysis. ACM Letterson Programming Languages and Systems, 1:323–337, 1992.

[MRR04] Ana Milanova, Atanas Rountev, and Barbara G. Ryder. Precisecall graphs for C programs with function pointers. AutomatedSoftware Engg., 11(1):7–26, 2004.

35

[NNH99] F. Nielson, H. Riis Nielson, and C. L. Hankin. Principles ofProgram Analysis. Springer, 1999.

[PAG] PAG - The Program Analyzer Generator - user’s manual. AbsIntAngewandte Informatik GmbH. http://www.absint.com/pag.

[PKH07] David J. Pearce, Paul H.J. Kelly, and Chris Hankin. Efficientfield-sensitive pointer analysis of C. ACM Trans. Program. Lang.Syst., 30(1):4, 2007.

[Ram94] G. Ramalingam. The undecidability of aliasing. ACM Trans.Program. Lang. Syst., 16(5):1467–1471, 1994.

[ROS] LLNL-ROSE. http://www.rosecompiler.org.

[Sch07] Markus Schordan. Combining tools and languages for staticanalysis and optimization of high-level abstractions, 2007.http://www.complang.tuwien.ac.at/markus.

[SH97] Marc Shapiro and Susan Horwitz. Fast and accurate flow-insensitive points-to analysis. In Symposium on Principles ofProgramming Languages, pages 1–14, 1997.

[SRW02] M. Sagiv, T. Reps, and R. Wilhelm. Parametric Shape Anal-ysis via 3-Valued Logic. ACM Transactions on ProgrammingLanguages and Systems, 24(3):217–298, 2002.

[Ste96] Bjarne Steensgaard. Points-to analysis by type inference of pro-grams with structures and unions. In Computational Complexity,pages 136–150, 1996.

[Tho98] Jerome Thoen. Sim6809, Motorola 6809 simulator, 1998.http://membres.lycos.fr/jth/6809.html, as of August 10, 2008.

[WL95] Robert P. Wilson and Monica S. Lam. Efficient context-sensitivepointer analysis for C programs. In SIGPLAN Conference onProgramming Language Design and Implementation, pages 1–12, 1995.

[WS07] Reinhard Wilhelm and Helmut Seidl. Ubersetzerbau: Program-manalyse und Optimierung, March 2007. Draft, handed out inlecture “Program Analysis and Transformation”, Saarland Uni-versity, summer term 2007.

36

function pointer analysis for c programs · iii. iv. abstract function pointers are a feature of...

Documents