Fixes #524

Co-authored-by: Alexey Alexandrov <aalexand@users.noreply.github.com>

* Remove seconds parameter

* Remove anoter seconds parameter

Provide more helpful error message and require input for every non-bool option.

Add support for output assembly in Intel Syntax.

* Check if location has a line with empty function

* Include context in the error message that will help triage the error

This keeps the column names visible when scrolling down, which comes in
handy when there are many entries.

The proto write type code stored in buffer stores unprintable values
(e.g. 2 when unmarshalling). The desired output when printing an error
message is the string representation of the integer (i.e. strconv.Itoa),
instead of the current behavior string(int) or string(rune), which
return the utf8 literal corresponding to the integer.

As pointed out by @ianlancetaylor in
https://github.com/google/pprof/commit/4ac0da8#commitcomment-37524728, commit
4ac0da8 preserves the previous incorrect behavior to pass a vet check,
whereas this change prints the desired output.

Updates golang/go#32479.

As per the vet check being introduced in 1.15
(https://github.com/golang/go/issues/32479), conversions of the form
string(int) are flagged by go vet. The suggested fix is to instead use
string(rune).

Additionally, since google/pprof is vendored into the go tree, we avoid
test failures from vet flagging this dependency (see
CL https://go-review.googlesource.com/c/go/+/220977).

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>