• Russ Cox's avatar
    cmd/gc, cmd/ld: struct field tracking · 3d40062c
    Russ Cox authored
    This is an experiment in static analysis of Go programs
    to understand which struct fields a program might use.
    It is not part of the Go language specification, it must
    be enabled explicitly when building the toolchain,
    and it may be removed at any time.
    
    After building the toolchain with GOEXPERIMENT=fieldtrack,
    a specific field can be marked for tracking by including
    `go:"track"` in the field tag:
    
            package pkg
    
            type T struct {
                    F int `go:"track"`
                    G int // untracked
            }
    
    To simplify usage, only named struct types can have
    tracked fields, and only exported fields can be tracked.
    
    The implementation works by making each function begin
    with a sequence of no-op USEFIELD instructions declaring
    which tracked fields are accessed by a specific function.
    After the linker's dead code elimination removes unused
    functions, the fields referred to by the remaining
    USEFIELD instructions are the ones reported as used by
    the binary.
    
    The -k option to the linker specifies the fully qualified
    symbol name (such as my/pkg.list) of a string variable that
    should be initialized with the field tracking information
    for the program. The field tracking string is a sequence
    of lines, each terminated by a \n and describing a single
    tracked field referred to by the program. Each line is made
    up of one or more tab-separated fields. The first field is
    the name of the tracked field, fully qualified, as in
    "my/pkg.T.F". Subsequent fields give a shortest path of
    reverse references from that field to a global variable or
    function, corresponding to one way in which the program
    might reach that field.
    
    A common source of false positives in field tracking is
    types with large method sets, because a reference to the
    type descriptor carries with it references to all methods.
    To address this problem, the CL also introduces a comment
    annotation
    
            //go:nointerface
    
    that marks an upcoming method declaration as unavailable
    for use in satisfying interfaces, both statically and
    dynamically. Such a method is also invisible to package
    reflect.
    
    Again, all of this is disabled by default. It only turns on
    if you have GOEXPERIMENT=fieldtrack set during make.bash.
    
    R=iant, ken
    CC=golang-dev
    https://golang.org/cl/6749064
    3d40062c
obj.c 15.1 KB