After importing pprof with #425 included to the Google's code base
a test in the symbolizer started to fail. The name of the test appears
to be related to handling the perf data from systems with kernel ASLR
related and this case turns out to depend on one of the heuristics I've
removed in #425 (I assumed that had only be used for user-mode
binaries). Add that heuristic back and add a test case with the input
equivalent to the internally failing test.

I have to say I do not quite understand the test case here as I thought
we already have a kernel ASLR test case here, and there the mmap offset
field looks more like a kernel page offset value (i.e. in the upper half
of the address space), but here it's a small number. For now just want
to make sure the existing test cases work as they were.

I was looking at a report where pprof wouldn't symbolize the data
collected for a Chrome binary using Linux perf (b/112303003). The mmap
information is:

start: 0000000002, limit: 0000000006, offset: 0000000002

The ELF file header:

elf.FileHeader{Class:elf.ELFCLASS64, Data:elf.ELFDATA2LSB, Version:elf.EV_CURRENT, OSABI:elf.ELFOSABI_NONE, ABIVersion:0x0, ByteOrder:binary.LittleEndian, Type:elf.ET_EXEC, Machine:elf.EM_X86_64, Entry:0x272e000}

The code segment:

elf.ProgHeader{Type:elf.PT_LOAD, Flags:elf.PF_X+elf.PF_R, Off:0x252f000,
Vaddr:0x272e000, Paddr:0x272e000, Filesz:0x43da610, Memsz:0x43da610,
Align:0x1000}

The dynamic loader here mapped 0x6b09000-0x272e000 = 0x43db000 bytes
starting 0x252f000 file offset into 0x272e000 virtual address, exactly
as instructed by the program header (so, no ASLR). Thus, the base
adjustment should be zero. Yet, the current GetBase produced the base of
0x252f000 which is wrong. The reason for that is that the ET_EXEC branch
of GetBase doesn't handle the general case of non-zero mmap file offset,
but rather only supports a couple of special cases. This change makes
handling the case of user-mode ET_EXEC more generic.

Add GetBase support for kernel mappings as reported by Linux Perf

Linux Perf reports kernel mappings with an offset == start.
Currently GetBase() cannot handle such a case.

This behavior can be seen from a perf.report data with samples in the kernel:

$ sudo perf report -D perf.data | grep MMAP
0 0x108 [0x50]: PERF_RECORD_MMAP -1/0: [0xffffffffaf800000(0x1087a000) @ 0xffffffffaf800000]: x [kernel.kallsyms]_text

Remove duplicate word "the"

When pprof symbolizes kernel addresses in vmlinux binary for a profile
converted using https://github.com/google/perf_data_converter, the
addresses need to be adjusted if kernel ASLR is in effect. So far the
call to GetBase did not pass text segment info to GetBase which
shortcircuited the code to merely return zero adjustment. This change
fixes the call to GetBase to address that.

The added test case is a simulation of what happens with vmlinux, but it
should be pretty close. Including a vmlinux file into the test data does
not appear practical due to the binary size. I verified that the test
failed before the fix and passes after.

Note that the fixed issue is specific to the kernel ASLR as user-mode
ASRL-enabled binaries (i.e. built with -pie / -fpie) have ET_DYN type
which takes a different code path in GetBase which did not have issues
before this fix in practice.

Generalize GetBase for shared libraries to handle cases when both process
mapping offset and program header addresses are non-zero.

Based on process mapping information, a sample at a virtual address x maps to
a file offset fx = x - map_start + map_offset.

The program header for the segment with the .text section may have non-zero
mapping information. Thus, a file offset fx maps to a symbol address
sx = fx - ph_offset + ph_virt_addr.

Thus, sx = x - map_start + map_offset - ph_offset + ph_virt_addr, and the base
address for symbolization is map_start - map_offset + ph_offset - ph_virt_addr.

* `git ls-files -- '*.go' | xargs gofmt -s -w`

* driver: unexport InternalOptions

This was an exported method that returned an internal type, so it's
unlikely that anyone depends on its presence.

* internal/binutils: remove newline in error string

golint reported: error strings should not be capitalized or end with
punctuation or a newline

* internal/driver: s/buildId/buildID/ per golint

* internal/elfexec: remove punctuation in error string

golint reported: error strings should not be capitalized or end with
punctuation or a newline

* internal/graph: correct comment

Found with golint.

* internal/graph: add method comment

golint reported: exported method Edge.WeightValue should have comment
or be unexported

* internal/report: remove newline in error string

golint reported: error strings should not be capitalized or end with
punctuation or a newline

* *: remove unused code

Found with honnef.co/go/tools/cmd/unused:

	internal/binutils/disasm_test.go:137:8: const objdump is unused (U1000)
	internal/driver/driver_test.go:353:6: type testProfile is unused (U1000)
	internal/graph/graph.go:838:6: func countEdges is unused (U1000)
	profile/proto.go:148:6: func encodeStringOpt is unused (U1000)

* *: simply code

Found with honnef.co/go/tools/cmd/gosimple:

	internal/driver/commands.go:471:24: should omit comparison to bool constant, can be simplified to !b (S1002)
	internal/driver/driver.go:163:5: should omit comparison to bool constant, can be simplified to !trim (S1002)
	internal/driver/driver.go:168:5: should omit comparison to bool constant, can be simplified to !focus (S1002)
	internal/driver/driver.go:172:5: should omit comparison to bool constant, can be simplified to !tagfocus (S1002)
	internal/driver/driver.go:176:5: should omit comparison to bool constant, can be simplified to !hide (S1002)
	internal/graph/dotgraph.go:213:34: should use make(map[string][]*Tag) instead (S1019)
	internal/report/report.go:1061:3: should replace loop with label = append(label, rpt.options.ProfileLabels...) (S1011)
	profile/proto.go:157:5: should omit comparison to bool constant, can be simplified to !x (S1002)

* *: correct mistakes

Found with honnef.co/go/tools/cmd/staticcheck:

	driver/driver.go:280:20: infinite recursive call (SA5007)
	internal/driver/driver_focus.go:54:11: this value of err is never used (SA4006)
	profile/proto.go:74:32: x | 0 always equals x (SA4016)

* Add linters to .travis.yml

- Remove dead code, unnecessary conversions
- Consistently use a single space after period

The kernel mapping record has the offset of 0xc000000000000000 on
PowerPC64 along with the same value for the mapping start.  Both values
come from arch/powerpc/Kconfig.  This case is not handled by any of the
conditions in the current getBase() code, so update the existing code
handling the kernel case to handle the PowerPC64 case.

This enables symbolization of some ChromeOS binaries.

Also update the build instructions to use go get