Overview ▹

Overview ▾

Package pointer implements Andersen's analysis, an inclusion-based pointer analysis algorithm first described in (Andersen, 1994).

A pointer analysis relates every pointer expression in a whole program to the set of memory locations to which it might point. This information can be used to construct a call graph of the program that precisely represents the destinations of dynamic function and method calls. It can also be used to determine, for example, which pairs of channel operations operate on the same channel.

The package allows the client to request a set of expressions of interest for which the points-to information will be returned once the analysis is complete. In addition, the client may request that a callgraph is constructed. The example program in example_test.go demonstrates both of these features. Clients should not request more information than they need since it may increase the cost of the analysis significantly.

CLASSIFICATION

Our algorithm is INCLUSION-BASED: the points-to sets for x and y will be related by pts(y) ⊇ pts(x) if the program contains the statement y = x.

It is FLOW-INSENSITIVE: it ignores all control flow constructs and the order of statements in a program. It is therefore a "MAY ALIAS" analysis: its facts are of the form "P may/may not point to L", not "P must point to L".

It is FIELD-SENSITIVE: it builds separate points-to sets for distinct fields, such as x and y in struct { x, y *int }.

It is mostly CONTEXT-INSENSITIVE: most functions are analyzed once, so values can flow in at one call to the function and return out at another. Only some smaller functions are analyzed with consideration of their calling context.

It has a CONTEXT-SENSITIVE HEAP: objects are named by both allocation site and context, so the objects returned by two distinct calls to f:

func f() *T { return new(T) }

are distinguished up to the limits of the calling context.

It is a WHOLE PROGRAM analysis: it requires SSA-form IR for the complete Go program and summaries for native code.

See the (Hind, PASTE'01) survey paper for an explanation of these terms.

SOUNDNESS

The analysis is fully sound when invoked on pure Go programs that do not use reflection or unsafe.Pointer conversions. In other words, if there is any possible execution of the program in which pointer P may point to object O, the analysis will report that fact.

REFLECTION

By default, the "reflect" library is ignored by the analysis, as if all its functions were no-ops, but if the client enables the Reflection flag, the analysis will make a reasonable attempt to model the effects of calls into this library. However, this comes at a significant performance cost, and not all features of that library are yet implemented. In addition, some simplifying approximations must be made to ensure that the analysis terminates; for example, reflection can be used to construct an infinite set of types and values of those types, but the analysis arbitrarily bounds the depth of such types.

Most but not all reflection operations are supported. In particular, addressable reflect.Values are not yet implemented, so operations such as (reflect.Value).Set have no analytic effect.

UNSAFE POINTER CONVERSIONS

The pointer analysis makes no attempt to understand aliasing between the operand x and result y of an unsafe.Pointer conversion:

y = (*T)(unsafe.Pointer(x))

It is as if the conversion allocated an entirely new object:

y = new(T)

NATIVE CODE

The analysis cannot model the aliasing effects of functions written in languages other than Go, such as runtime intrinsics in C or assembly, or code accessed via cgo. The result is as if such functions are no-ops. However, various important intrinsics are understood by the analysis, along with built-ins such as append.

The analysis currently provides no way for users to specify the aliasing effects of native code.

------------------------------------------------------------------------

IMPLEMENTATION

The remaining documentation is intended for package maintainers and pointer analysis specialists. Maintainers should have a solid understanding of the referenced papers (especially those by H&L and PKH) before making making significant changes.

The implementation is similar to that described in (Pearce et al, PASTE'04). Unlike many algorithms which interleave constraint generation and solving, constructing the callgraph as they go, this implementation for the most part observes a phase ordering (generation before solving), with only simple (copy) constraints being generated during solving. (The exception is reflection, which creates various constraints during solving as new types flow to reflect.Value operations.) This improves the traction of presolver optimisations, but imposes certain restrictions, e.g. potential context sensitivity is limited since all variants must be created a priori.

TERMINOLOGY

A type is said to be "pointer-like" if it is a reference to an object. Pointer-like types include pointers and also interfaces, maps, channels, functions and slices.

We occasionally use C's x->f notation to distinguish the case where x is a struct pointer from x.f where is a struct value.

Pointer analysis literature (and our comments) often uses the notation dst=*src+offset to mean something different than what it means in Go. It means: for each node index p in pts(src), the node index p+offset is in pts(dst). Similarly *dst+offset=src is used for store constraints and dst=src+offset for offset-address constraints.

NODES

Nodes are the key datastructure of the analysis, and have a dual role: they represent both constraint variables (equivalence classes of pointers) and members of points-to sets (things that can be pointed at, i.e. "labels").

Nodes are naturally numbered. The numbering enables compact representations of sets of nodes such as bitvectors (or BDDs); and the ordering enables a very cheap way to group related nodes together. For example, passing n parameters consists of generating n parallel constraints from caller+i to callee+i for 0<=i<n.

The zero nodeid means "not a pointer". For simplicity, we generate flow constraints even for non-pointer types such as int. The pointer equivalence (PE) presolver optimization detects which variables cannot point to anything; this includes not only all variables of non-pointer types (such as int) but also variables of pointer-like types if they are always nil, or are parameters to a function that is never called.

Each node represents a scalar part of a value or object. Aggregate types (structs, tuples, arrays) are recursively flattened out into a sequential list of scalar component types, and all the elements of an array are represented by a single node. (The flattening of a basic type is a list containing a single node.)

Nodes are connected into a graph with various kinds of labelled edges: simple edges (or copy constraints) represent value flow. Complex edges (load, store, etc) trigger the creation of new simple edges during the solving phase.

OBJECTS

Conceptually, an "object" is a contiguous sequence of nodes denoting an addressable location: something that a pointer can point to. The first node of an object has a non-nil obj field containing information about the allocation: its size, context, and ssa.Value.

Objects include:

- functions and globals;
- variable allocations in the stack frame or heap;
- maps, channels and slices created by calls to make();
- allocations to construct an interface;
- allocations caused by conversions, e.g. []byte(str).
- arrays allocated by calls to append();

Many objects have no Go types. For example, the func, map and chan type kinds in Go are all varieties of pointers, but their respective objects are actual functions (executable code), maps (hash tables), and channels (synchronized queues). Given the way we model interfaces, they too are pointers to "tagged" objects with no Go type. And an *ssa.Global denotes the address of a global variable, but the object for a Global is the actual data. So, the types of an ssa.Value that creates an object is "off by one indirection": a pointer to the object.

The individual nodes of an object are sometimes referred to as "labels".

For uniformity, all objects have a non-zero number of fields, even those of the empty type struct{}. (All arrays are treated as if of length 1, so there are no empty arrays. The empty tuple is never address-taken, so is never an object.)

TAGGED OBJECTS

An tagged object has the following layout:

T          -- obj.flags ⊇ {otTagged}
v
...

The T node's typ field is the dynamic type of the "payload": the value v which follows, flattened out. The T node's obj has the otTagged flag.

Tagged objects are needed when generalizing across types: interfaces, reflect.Values, reflect.Types. Each of these three types is modelled as a pointer that exclusively points to tagged objects.

Tagged objects may be indirect (obj.flags ⊇ {otIndirect}) meaning that the value v is not of type T but *T; this is used only for reflect.Values that represent lvalues. (These are not implemented yet.)

ANALYSIS ABSTRACTION OF EACH TYPE

Variables of the following "scalar" types may be represented by a single node: basic types, pointers, channels, maps, slices, 'func' pointers, interfaces.

Pointers

Nothing to say here, oddly.

Basic types (bool, string, numbers, unsafe.Pointer)

Currently all fields in the flattening of a type, including
non-pointer basic types such as int, are represented in objects and
values.  Though non-pointer nodes within values are uninteresting,
non-pointer nodes in objects may be useful (if address-taken)
because they permit the analysis to deduce, in this example,

   var s struct{ ...; x int; ... }
   p := &s.x

that p points to s.x.  If we ignored such object fields, we could only
say that p points somewhere within s.

All other basic types are ignored.  Expressions of these types have
zero nodeid, and fields of these types within aggregate other types
are omitted.

unsafe.Pointers are not modelled as pointers, so a conversion of an
unsafe.Pointer to *T is (unsoundly) treated equivalent to new(T).

Channels

An expression of type 'chan T' is a kind of pointer that points
exclusively to channel objects, i.e. objects created by MakeChan (or
reflection).

'chan T' is treated like *T.
*ssa.MakeChan is treated as equivalent to new(T).
*ssa.Send and receive (*ssa.UnOp(ARROW)) and are equivalent to store
 and load.

Maps

An expression of type 'map[K]V' is a kind of pointer that points
exclusively to map objects, i.e. objects created by MakeMap (or
reflection).

map K[V] is treated like *M where M = struct{k K; v V}.
*ssa.MakeMap is equivalent to new(M).
*ssa.MapUpdate is equivalent to *y=x where *y and x have type M.
*ssa.Lookup is equivalent to y=x.v where x has type *M.

Slices

A slice []T, which dynamically resembles a struct{array *T, len, cap int},
is treated as if it were just a *T pointer; the len and cap fields are
ignored.

*ssa.MakeSlice is treated like new([1]T): an allocation of a
 singleton array.
*ssa.Index on a slice is equivalent to a load.
*ssa.IndexAddr on a slice returns the address of the sole element of the
slice, i.e. the same address.
*ssa.Slice is treated as a simple copy.

Functions

An expression of type 'func...' is a kind of pointer that points
exclusively to function objects.

A function object has the following layout:

   identity         -- typ:*types.Signature; obj.flags ⊇ {otFunction}
   params_0         -- (the receiver, if a method)
   ...
   params_n-1
   results_0
   ...
   results_m-1

There may be multiple function objects for the same *ssa.Function
due to context-sensitive treatment of some functions.

The first node is the function's identity node.
Associated with every callsite is a special "targets" variable,
whose pts() contains the identity node of each function to which
the call may dispatch.  Identity words are not otherwise used during
the analysis, but we construct the call graph from the pts()
solution for such nodes.

The following block of contiguous nodes represents the flattened-out
types of the parameters ("P-block") and results ("R-block") of the
function object.

The treatment of free variables of closures (*ssa.FreeVar) is like
that of global variables; it is not context-sensitive.
*ssa.MakeClosure instructions create copy edges to Captures.

A Go value of type 'func' (i.e. a pointer to one or more functions)
is a pointer whose pts() contains function objects.  The valueNode()
for an *ssa.Function returns a singleton for that function.

Interfaces

An expression of type 'interface{...}' is a kind of pointer that
points exclusively to tagged objects.  All tagged objects pointed to
by an interface are direct (the otIndirect flag is clear) and
concrete (the tag type T is not itself an interface type).  The
associated ssa.Value for an interface's tagged objects may be an
*ssa.MakeInterface instruction, or nil if the tagged object was
created by an instrinsic (e.g. reflection).

Constructing an interface value causes generation of constraints for
all of the concrete type's methods; we can't tell a priori which
ones may be called.

TypeAssert y = x.(T) is implemented by a dynamic constraint
triggered by each tagged object O added to pts(x): a typeFilter
constraint if T is an interface type, or an untag constraint if T is
a concrete type.  A typeFilter tests whether O.typ implements T; if
so, O is added to pts(y).  An untagFilter tests whether O.typ is
assignable to T,and if so, a copy edge O.v -> y is added.

ChangeInterface is a simple copy because the representation of
tagged objects is independent of the interface type (in contrast
to the "method tables" approach used by the gc runtime).

y := Invoke x.m(...) is implemented by allocating contiguous P/R
blocks for the callsite and adding a dynamic rule triggered by each
tagged object added to pts(x).  The rule adds param/results copy
edges to/from each discovered concrete method.

(Q. Why do we model an interface as a pointer to a pair of type and
value, rather than as a pair of a pointer to type and a pointer to
value?
A. Control-flow joins would merge interfaces ({T1}, {V1}) and ({T2},
{V2}) to make ({T1,T2}, {V1,V2}), leading to the infeasible and
type-unsafe combination (T1,V2).  Treating the value and its concrete
type as inseparable makes the analysis type-safe.)

reflect.Value

A reflect.Value is modelled very similar to an interface{}, i.e. as
a pointer exclusively to tagged objects, but with two generalizations.

1) a reflect.Value that represents an lvalue points to an indirect
   (obj.flags ⊇ {otIndirect}) tagged object, which has a similar
   layout to an tagged object except that the value is a pointer to
   the dynamic type.  Indirect tagged objects preserve the correct
   aliasing so that mutations made by (reflect.Value).Set can be
   observed.

   Indirect objects only arise when an lvalue is derived from an
   rvalue by indirection, e.g. the following code:

      type S struct { X T }
      var s S
      var i interface{} = &s    // i points to a *S-tagged object (from MakeInterface)
      v1 := reflect.ValueOf(i)  // v1 points to same *S-tagged object as i
      v2 := v1.Elem()           // v2 points to an indirect S-tagged object, pointing to s
      v3 := v2.FieldByName("X") // v3 points to an indirect int-tagged object, pointing to s.X
      v3.Set(y)                 // pts(s.X) ⊇ pts(y)

   Whether indirect or not, the concrete type of the tagged object
   corresponds to the user-visible dynamic type, and the existence
   of a pointer is an implementation detail.

   (NB: indirect tagged objects are not yet implemented)

2) The dynamic type tag of a tagged object pointed to by a
   reflect.Value may be an interface type; it need not be concrete.

   This arises in code such as this:
      tEface := reflect.TypeOf(new(interface{}).Elem() // interface{}
      eface := reflect.Zero(tEface)
   pts(eface) is a singleton containing an interface{}-tagged
   object.  That tagged object's payload is an interface{} value,
   i.e. the pts of the payload contains only concrete-tagged
   objects, although in this example it's the zero interface{} value,
   so its pts is empty.

reflect.Type

Just as in the real "reflect" library, we represent a reflect.Type
as an interface whose sole implementation is the concrete type,
*reflect.rtype.  (This choice is forced on us by go/types: clients
cannot fabricate types with arbitrary method sets.)

rtype instances are canonical: there is at most one per dynamic
type.  (rtypes are in fact large structs but since identity is all
that matters, we represent them by a single node.)

The payload of each *rtype-tagged object is an *rtype pointer that
points to exactly one such canonical rtype object.  We exploit this
by setting the node.typ of the payload to the dynamic type, not
'*rtype'.  This saves us an indirection in each resolution rule.  As
an optimisation, *rtype-tagged objects are canonicalized too.

Aggregate types:

Aggregate types are treated as if all directly contained aggregates are recursively flattened out.

Structs

*ssa.Field y = x.f creates a simple edge to y from x's node at f's offset.

*ssa.FieldAddr y = &x->f requires a dynamic closure rule to create
 simple edges for each struct discovered in pts(x).

The nodes of a struct consist of a special 'identity' node (whose
type is that of the struct itself), followed by the nodes for all
the struct's fields, recursively flattened out.  A pointer to the
struct is a pointer to its identity node.  That node allows us to
distinguish a pointer to a struct from a pointer to its first field.

Field offsets are logical field offsets (plus one for the identity
node), so the sizes of the fields can be ignored by the analysis.

(The identity node is non-traditional but enables the distiction
described above, which is valuable for code comprehension tools.
Typical pointer analyses for C, whose purpose is compiler
optimization, must soundly model unsafe.Pointer (void*) conversions,
and this requires fidelity to the actual memory layout using physical
field offsets.)

*ssa.Field y = x.f creates a simple edge to y from x's node at f's offset.

*ssa.FieldAddr y = &x->f requires a dynamic closure rule to create
 simple edges for each struct discovered in pts(x).

Arrays

We model an array by an identity node (whose type is that of the
array itself) followed by a node representing all the elements of
the array; the analysis does not distinguish elements with different
indices.  Effectively, an array is treated like struct{elem T}, a
load y=x[i] like y=x.elem, and a store x[i]=y like x.elem=y; the
index i is ignored.

A pointer to an array is pointer to its identity node.  (A slice is
also a pointer to an array's identity node.)  The identity node
allows us to distinguish a pointer to an array from a pointer to one
of its elements, but it is rather costly because it introduces more
offset constraints into the system.  Furthermore, sound treatment of
unsafe.Pointer would require us to dispense with this node.

Arrays may be allocated by Alloc, by make([]T), by calls to append,
and via reflection.

Tuples (T, ...)

Tuples are treated like structs with naturally numbered fields.
*ssa.Extract is analogous to *ssa.Field.

However, tuples have no identity field since by construction, they
cannot be address-taken.

FUNCTION CALLS

There are three kinds of function call:
(1) static "call"-mode calls of functions.
(2) dynamic "call"-mode calls of functions.
(3) dynamic "invoke"-mode calls of interface methods.
Cases 1 and 2 apply equally to methods and standalone functions.

Static calls.
  A static call consists three steps:
  - finding the function object of the callee;
  - creating copy edges from the actual parameter value nodes to the
    P-block in the function object (this includes the receiver if
    the callee is a method);
  - creating copy edges from the R-block in the function object to
    the value nodes for the result of the call.

  A static function call is little more than two struct value copies
  between the P/R blocks of caller and callee:

     callee.P = caller.P
     caller.R = callee.R

  Context sensitivity

    Static calls (alone) may be treated context sensitively,
    i.e. each callsite may cause a distinct re-analysis of the
    callee, improving precision.  Our current context-sensitivity
    policy treats all intrinsics and getter/setter methods in this
    manner since such functions are small and seem like an obvious
    source of spurious confluences, though this has not yet been
    evaluated.

Dynamic function calls

  Dynamic calls work in a similar manner except that the creation of
  copy edges occurs dynamically, in a similar fashion to a pair of
  struct copies in which the callee is indirect:

     callee->P = caller.P
     caller.R = callee->R

  (Recall that the function object's P- and R-blocks are contiguous.)

Interface method invocation

  For invoke-mode calls, we create a params/results block for the
  callsite and attach a dynamic closure rule to the interface.  For
  each new tagged object that flows to the interface, we look up
  the concrete method, find its function object, and connect its P/R
  blocks to the callsite's P/R blocks, adding copy edges to the graph
  during solving.

Recording call targets

  The analysis notifies its clients of each callsite it encounters,
  passing a CallSite interface.  Among other things, the CallSite
  contains a synthetic constraint variable ("targets") whose
  points-to solution includes the set of all function objects to
  which the call may dispatch.

  It is via this mechanism that the callgraph is made available.
  Clients may also elect to be notified of callgraph edges directly;
  internally this just iterates all "targets" variables' pts(·)s.

PRESOLVER

We implement Hash-Value Numbering (HVN), a pre-solver constraint optimization described in Hardekopf & Lin, SAS'07. This is documented in more detail in hvn.go. We intend to add its cousins HR and HU in future.

SOLVER

The solver is currently a naive Andersen-style implementation; it does not perform online cycle detection, though we plan to add solver optimisations such as Hybrid- and Lazy- Cycle Detection from (Hardekopf & Lin, PLDI'07).

It uses difference propagation (Pearce et al, SQC'04) to avoid redundant re-triggering of closure rules for values already seen.

Points-to sets are represented using sparse bit vectors (similar to those used in LLVM and gcc), which are more space- and time-efficient than sets based on Go's built-in map type or dense bit vectors.

Nodes are permuted prior to solving so that object nodes (which may appear in points-to sets) are lower numbered than non-object (var) nodes. This improves the density of the set over which the PTSs range, and thus the efficiency of the representation.

Partly thanks to avoiding map iteration, the execution of the solver is 100% deterministic, a great help during debugging.

Package pointer

Overview ▹

Overview ▾

CLASSIFICATION

SOUNDNESS

REFLECTION

UNSAFE POINTER CONVERSIONS

NATIVE CODE

IMPLEMENTATION

TERMINOLOGY

NODES

OBJECTS

TAGGED OBJECTS

ANALYSIS ABSTRACTION OF EACH TYPE

PRESOLVER

SOLVER

FURTHER READING

Index ▹

Index ▾

Examples

Package files

Internal call graph ▹

Internal call graph ▾

func CanHaveDynamicTypes ¶

func CanPoint ¶

type Config ¶

func (*Config) AddExtendedQuery ¶

func (*Config) AddIndirectQuery ¶

func (*Config) AddQuery ¶

type Label ¶

func (Label) Path ¶

func (Label) Pos ¶

func (Label) ReflectType ¶

func (Label) String ¶

func (Label) Value ¶

type Pointer ¶

func (Pointer) DynamicTypes ¶

func (Pointer) MayAlias ¶

func (Pointer) PointsTo ¶

func (Pointer) String ¶

type PointsToSet ¶

func (PointsToSet) DynamicTypes ¶

func (PointsToSet) Intersects ¶

func (PointsToSet) Labels ¶

func (PointsToSet) String ¶

type Result ¶

func Analyze ¶

type Warning ¶