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

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.

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.

Also update the build instructions to use go get