Co-authored-by: Maggie Nolan <nolanmar@google.com>

Tag filters like `-tagfilter=foo=1` currently cannot be used to filter
by a unitless numeric tag as the tag filter regular expression expects
the unit part to be always present.  They can be made working by using
`-tagfilter=foo=1unit` instead, but that's weird syntax. So fix this by
merely making the unit part optional.

I was wondering if this simple fix could have any unintended effects but
as far as I can tell from testing it does not.

This allows averaging profiles by using:
pprof -proto output --divide_by <n> profile1.pb.gz ... profilen.pb.gz

* Add go.mod/go.sum

* travis: update to test in modules mode and with go1.13

Remove go1.11 setup

* fix appveyor config

AppVeyor sets the latest go stack in C:\go and that is GOROOT.
Cloning this repo under C:\go\src\.. directory confused go build
(as discussed in golang/go#34657). The fix in go is not yet
released. Thus this commit changes GOPATH to c:\gopath and clones
the repo under the directory.

Also, this commit removes the go get commands intended to pull in
dependencies. In modules mode, `go build` pulls in the required
dependencies.

This sorts flamegraph elements lexographiaclly such that two similar
profiles can be compared side-by-side to eyeball differences in
flamegraph profile shapes and sizes.

This adds flamegraph to the list of dynamic search links so that query parameters are retained when navigating to/from the flamegraph view.

This is similar to such flag in driver_test.go and dotgraph_test.go.

I had this change locally for some time, would like to check this in.

Also stop supporting Go 1.10 as Go 1.12 is out.

Fix comments according to best practices by effective go

Signed-off-by: CodeLingo Bot <bot@codelingo.io>

Propagate query args during URL redirect to preserve heap allocation type

Support sign in tagfocus

Also update the text around supported Go versions - refer to the
Go's policy on that which is two latest major releases.

* bump Go versions;
* bump macOS / Xcode versions;
* use homebrew addon to install graphviz.

Support https with server certificate.

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.

simplify function names in graph and flame

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.

Signed-off-by: Jongmin Kim <jmkim@pukyong.ac.kr>

This change consists of two relatively independent parts, but they are
both about handling the granularity, so bundling them together.

First, in #415 there is a discussion that having a granularity mode by
source lines but with inlines hidden would be useful. The agreement is
also that adding `-linenoinlines` granularity would make the granularity
flags too messy (and they are already somewhat messy with `-addresses`
and `-addressnoinlines`. So, it was proposed to make `-noinlines` a
separate flag, which is what this change does. Note that the flag is now
pulled out of the granularity group so it's a bit of backward
incompatible change but I think it is acceptable. For the example in
issue #415 the user would now be able to specify `-list foo -noinlines`
to produce annotated source where the metrics from the inlined functions
are attributed to the calling inliner line.

With this change, I am also dropping the `-addressnoinlines` granularity
which is now supported as `-addresses -noinlines` combination. I
couldn't find any usage of this option at least internally at Google, so
I think it's safe to remove it.

Second, I am adding a separate `-filefunctions` granularity which groups
the data by both function and file. This is a follow-up to #110 from the
past where we changed the `-functions` granularity to not group by file
(it used to), and since then there was a couple of reports where using
just function name alone would over-aggregate the data in cases when a
function with the same name is contained in multiple source files (e.g.
see b/18874275 internally).

Also, make a number of assorted documentation and `-help` fixes.

Change order of commands returned by browser to prioritize commands used to open browsers on windows and mac

* change order of commands returned by browser()

* Add comment to explain browser command order

This is a follow up change to #412 which adds a selector to the web
ui for selecting the sample index of a profile to view. The selector
is hidden for profiles with only a single sample type.

Add support for fat Mach-O files

Fixes #1033. Note that this does not do the "correct" thing, of checking the main executable to see what architecture it is and trying to match that. Or maybe checking the architecture in the profile file if it is present.

Instead it just uses the host architecture to decide which subfile of the fat archive to open.

The option is exposed in the web ui's query string under a
new `?si=<sample_index>` parameter. This is particularly
useful for heap profiles, where switching between the four
indices (alloc_objects, alloc_space, inuse_objects, and inuse_space)
is a common task.

We could add a menu to the UI to make discovery of these
options easier, but for now this seems sufficient.

Improve "unrecognized binary" error messages

Previously it would just print "unrecognized binary" no matter what the underlying error message was. This was partly because it was unable to know the actual file type except by trial and error. This commit uses the magic number instead. It also gives a nicer error for fat Mach-O binaries which are currently unsupported.