mirror of
https://github.com/golang/go
synced 2024-09-30 10:28:33 -06:00
cmd/vendor/README: temporary instruction for update
Until vgo sorts out and cleans up the vendoring process. Ran govendor to update packages the cmd/pprof depends on which resulted in deletion of some of unnecessary files. Change-Id: Idfba53e94414e90a5e280222750a6df77e979a16 Reviewed-on: https://go-review.googlesource.com/114079 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
This commit is contained in:
parent
402dd10a99
commit
51be90a251
21
src/cmd/vendor/README
vendored
Normal file
21
src/cmd/vendor/README
vendored
Normal file
@ -0,0 +1,21 @@
|
||||
How to update the vendored packages:
|
||||
|
||||
Assuming the govendor tool is available
|
||||
run the govendor tool from src/cmd directory
|
||||
|
||||
$ go get -u github.com/kardianos/govendor
|
||||
|
||||
To update packages used by cmd/pprof:
|
||||
|
||||
$ cd $GOROOT/src/cmd
|
||||
$ GOPATH=$GOROOT govendor fetch github.com/google/pprof/...
|
||||
|
||||
To update packages used by internal/objfile/*:
|
||||
|
||||
$ GOPATH=$GOROOT govendor fetch golang.org/x/arch/...
|
||||
|
||||
GOPATH=$GOROOT in the above commands is a hack to
|
||||
make govendor work and will create the .cache folder in
|
||||
$GOROOT as a side-effect. Please make sure to delete
|
||||
the directory and not to include the directory in the
|
||||
commit by accident.
|
7
src/cmd/vendor/github.com/google/pprof/AUTHORS
generated
vendored
7
src/cmd/vendor/github.com/google/pprof/AUTHORS
generated
vendored
@ -1,7 +0,0 @@
|
||||
# This is the official list of pprof authors for copyright purposes.
|
||||
# This file is distinct from the CONTRIBUTORS files.
|
||||
# See the latter for an explanation.
|
||||
# Names should be added to this file as:
|
||||
# Name or Organization <email address>
|
||||
# The email address is not required for organizations.
|
||||
Google Inc.
|
77
src/cmd/vendor/github.com/google/pprof/CONTRIBUTING.md
generated
vendored
77
src/cmd/vendor/github.com/google/pprof/CONTRIBUTING.md
generated
vendored
@ -1,77 +0,0 @@
|
||||
Want to contribute? Great: read the page (including the small print at the end).
|
||||
|
||||
# Before you contribute
|
||||
|
||||
As an individual, sign the [Google Individual Contributor License
|
||||
Agreement](https://cla.developers.google.com/about/google-individual) (CLA)
|
||||
online. This is required for any of your code to be accepted.
|
||||
|
||||
Before you start working on a larger contribution, get in touch with us first
|
||||
through the issue tracker with your idea so that we can help out and possibly
|
||||
guide you. Coordinating up front makes it much easier to avoid frustration later
|
||||
on.
|
||||
|
||||
# Development
|
||||
|
||||
Make sure `GOPATH` is set in your current shell. The common way is to have
|
||||
something like `export GOPATH=$HOME/gocode` in your `.bashrc` file so that it's
|
||||
automatically set in all console sessions.
|
||||
|
||||
To get the source code, run
|
||||
|
||||
```
|
||||
go get github.com/google/pprof
|
||||
```
|
||||
|
||||
To run the tests, do
|
||||
|
||||
```
|
||||
cd $GOPATH/src/github.com/google/pprof
|
||||
go test -v ./...
|
||||
```
|
||||
|
||||
When you wish to work with your own fork of the source (which is required to be
|
||||
able to create a pull request), you'll want to get your fork repo as another Git
|
||||
remote in the same `github.com/google/pprof` directory. Otherwise, if you'll `go
|
||||
get` your fork directly, you'll be getting errors like `use of internal package
|
||||
not allowed` when running tests. To set up the remote do something like
|
||||
|
||||
```
|
||||
cd $GOPATH/src/github.com/google/pprof
|
||||
git remote add aalexand git@github.com:aalexand/pprof.git
|
||||
git fetch aalexand
|
||||
git checkout -b my-new-feature
|
||||
# hack hack hack
|
||||
go test -v ./...
|
||||
git commit -a -m "Add new feature."
|
||||
git push aalexand
|
||||
```
|
||||
|
||||
where `aalexand` is your GitHub user ID. Then proceed to the GitHub UI to send a
|
||||
code review.
|
||||
|
||||
# Code reviews
|
||||
|
||||
All submissions, including submissions by project members, require review.
|
||||
We use GitHub pull requests for this purpose.
|
||||
|
||||
The pprof source code is in Go with a bit of JavaScript, CSS and HTML. If you
|
||||
are new to Go, read [Effective Go](https://golang.org/doc/effective_go.html) and
|
||||
the [summary on typical comments during Go code
|
||||
reviews](https://github.com/golang/go/wiki/CodeReviewComments).
|
||||
|
||||
Cover all new functionality with tests. Enable Travis on your forked repo,
|
||||
enable builds of branches and make sure Travis is happily green for the branch
|
||||
with your changes.
|
||||
|
||||
The code coverage is measured for each pull request. The code coverage is
|
||||
expected to go up with every change.
|
||||
|
||||
Pull requests not meeting the above guidelines will get less attention than good
|
||||
ones, so make sure your submissions are high quality.
|
||||
|
||||
# The small print
|
||||
|
||||
Contributions made by corporations are covered by a different agreement than the
|
||||
one above, the [Software Grant and Corporate Contributor License
|
||||
Agreement](https://cla.developers.google.com/about/google-corporate).
|
15
src/cmd/vendor/github.com/google/pprof/CONTRIBUTORS
generated
vendored
15
src/cmd/vendor/github.com/google/pprof/CONTRIBUTORS
generated
vendored
@ -1,15 +0,0 @@
|
||||
# People who have agreed to one of the CLAs and can contribute patches.
|
||||
# The AUTHORS file lists the copyright holders; this file
|
||||
# lists people. For example, Google employees are listed here
|
||||
# but not in AUTHORS, because Google holds the copyright.
|
||||
#
|
||||
# https://developers.google.com/open-source/cla/individual
|
||||
# https://developers.google.com/open-source/cla/corporate
|
||||
#
|
||||
# Names should be added to this file as:
|
||||
# Name <email address>
|
||||
Raul Silvera <rsilvera@google.com>
|
||||
Tipp Moseley <tipp@google.com>
|
||||
Hyoun Kyu Cho <netforce@google.com>
|
||||
Martin Spier <spiermar@gmail.com>
|
||||
Taco de Wolff <tacodewolff@gmail.com>
|
109
src/cmd/vendor/github.com/google/pprof/README.md
generated
vendored
109
src/cmd/vendor/github.com/google/pprof/README.md
generated
vendored
@ -1,109 +0,0 @@
|
||||
[![Build Status](https://travis-ci.org/google/pprof.svg?branch=master)](https://travis-ci.org/google/pprof)
|
||||
[![codecov](https://codecov.io/gh/google/pprof/graph/badge.svg)](https://codecov.io/gh/google/pprof)
|
||||
|
||||
# Introduction
|
||||
|
||||
pprof is a tool for visualization and analysis of profiling data.
|
||||
|
||||
pprof reads a collection of profiling samples in profile.proto format and
|
||||
generates reports to visualize and help analyze the data. It can generate both
|
||||
text and graphical reports (through the use of the dot visualization package).
|
||||
|
||||
profile.proto is a protocol buffer that describes a set of callstacks
|
||||
and symbolization information. A common usage is to represent a set of
|
||||
sampled callstacks from statistical profiling. The format is
|
||||
described on the [proto/profile.proto](./proto/profile.proto) file. For details on protocol
|
||||
buffers, see https://developers.google.com/protocol-buffers
|
||||
|
||||
Profiles can be read from a local file, or over http. Multiple
|
||||
profiles of the same type can be aggregated or compared.
|
||||
|
||||
If the profile samples contain machine addresses, pprof can symbolize
|
||||
them through the use of the native binutils tools (addr2line and nm).
|
||||
|
||||
**This is not an official Google product.**
|
||||
|
||||
# Building pprof
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Go development kit. Requires Go 1.7 or newer.
|
||||
Follow [these instructions](http://golang.org/doc/code.html) to install the
|
||||
go tool and set up GOPATH.
|
||||
|
||||
- Graphviz: http://www.graphviz.org/
|
||||
Optional, used to generate graphic visualizations of profiles
|
||||
|
||||
To build and install it, use the `go get` tool.
|
||||
|
||||
go get github.com/google/pprof
|
||||
|
||||
Remember to set GOPATH to the directory where you want pprof to be
|
||||
installed. The binary will be in `$GOPATH/bin` and the sources under
|
||||
`$GOPATH/src/github.com/google/pprof`.
|
||||
|
||||
# Basic usage
|
||||
|
||||
pprof can read a profile from a file or directly from a server via http.
|
||||
Specify the profile input(s) in the command line, and use options to
|
||||
indicate how to format the report.
|
||||
|
||||
## Generate a text report of the profile, sorted by hotness:
|
||||
|
||||
```
|
||||
% pprof -top [main_binary] profile.pb.gz
|
||||
Where
|
||||
main_binary: Local path to the main program binary, to enable symbolization
|
||||
profile.pb.gz: Local path to the profile in a compressed protobuf, or
|
||||
URL to the http service that serves a profile.
|
||||
```
|
||||
|
||||
## Generate a graph in an SVG file, and open it with a web browser:
|
||||
|
||||
```
|
||||
pprof -web [main_binary] profile.pb.gz
|
||||
```
|
||||
|
||||
## Run pprof on interactive mode:
|
||||
|
||||
If no output formatting option is specified, pprof runs on interactive mode,
|
||||
where reads the profile and accepts interactive commands for visualization and
|
||||
refinement of the profile.
|
||||
|
||||
```
|
||||
pprof [main_binary] profile.pb.gz
|
||||
|
||||
This will open a simple shell that takes pprof commands to generate reports.
|
||||
Type 'help' for available commands/options.
|
||||
```
|
||||
|
||||
## Run pprof via a web interface
|
||||
|
||||
If the `-http` flag is specified, pprof starts a web server at
|
||||
the specified host:port that provides an interactive web-based interface to pprof.
|
||||
Host is optional, and is "localhost" by default. Port is optional, and is a
|
||||
random available port by default. `-http=":"` starts a server locally at
|
||||
a random port.
|
||||
|
||||
```
|
||||
pprof -http=[host]:[port] [main_binary] profile.pb.gz
|
||||
```
|
||||
|
||||
The preceding command should automatically open your web browser at
|
||||
the right page; if not, you can manually visit the specified port in
|
||||
your web browser.
|
||||
|
||||
## Using pprof with Linux Perf
|
||||
|
||||
pprof can read `perf.data` files generated by the
|
||||
[Linux perf](https://perf.wiki.kernel.org/index.php/Main_Page) tool by using the
|
||||
`perf_to_profile` program from the
|
||||
[perf_data_converter](https://github.com/google/perf_data_converter) package.
|
||||
|
||||
## Further documentation
|
||||
|
||||
See [doc/README.md](doc/README.md) for more detailed end-user documentation.
|
||||
|
||||
See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution documentation.
|
||||
|
||||
See [proto/README.md](proto/README.md) for a description of the profile.proto format.
|
289
src/cmd/vendor/github.com/google/pprof/doc/README.md
generated
vendored
289
src/cmd/vendor/github.com/google/pprof/doc/README.md
generated
vendored
@ -1,289 +0,0 @@
|
||||
# pprof
|
||||
|
||||
pprof is a tool for visualization and analysis of profiling data.
|
||||
|
||||
pprof reads a collection of profiling samples in profile.proto format and
|
||||
generates reports to visualize and help analyze the data. It can generate both
|
||||
text and graphical reports (through the use of the dot visualization package).
|
||||
|
||||
profile.proto is a protocol buffer that describes a set of callstacks
|
||||
and symbolization information. A common usage is to represent a set of
|
||||
sampled callstacks from statistical profiling. The format is
|
||||
described on the src/proto/profile.proto file. For details on protocol
|
||||
buffers, see https://developers.google.com/protocol-buffers
|
||||
|
||||
Profiles can be read from a local file, or over http. Multiple
|
||||
profiles of the same type can be aggregated or compared.
|
||||
|
||||
If the profile samples contain machine addresses, pprof can symbolize
|
||||
them through the use of the native binutils tools (addr2line and nm).
|
||||
|
||||
# pprof profiles
|
||||
|
||||
pprof operates on data in the profile.proto format. Each profile is a collection
|
||||
of samples, where each sample is associated to a point in a location hierarchy,
|
||||
one or more numeric values, and a set of labels. Often these profiles represents
|
||||
data collected through statistical sampling of a program, so each sample
|
||||
describes a program call stack and a number or weight of samples collected at a
|
||||
location. pprof is agnostic to the profile semantics, so other uses are
|
||||
possible. The interpretation of the reports generated by pprof depends on the
|
||||
semantics defined by the source of the profile.
|
||||
|
||||
# Usage Modes
|
||||
|
||||
There are few different ways of using `pprof`.
|
||||
|
||||
## Report generation
|
||||
|
||||
If a report format is requested on the command line:
|
||||
|
||||
pprof <format> [options] source
|
||||
|
||||
pprof will generate a report in the specified format and exit.
|
||||
Formats can be either text, or graphical. See below for details about
|
||||
supported formats, options, and sources.
|
||||
|
||||
## Interactive terminal use
|
||||
|
||||
Without a format specifier:
|
||||
|
||||
pprof [options] source
|
||||
|
||||
pprof will start an interactive shell in which the user can type
|
||||
commands. Type `help` to get online help.
|
||||
|
||||
## Web interface
|
||||
|
||||
If a host:port is specified on the command line:
|
||||
|
||||
pprof -http=[host]:[port] [options] source
|
||||
|
||||
pprof will start serving HTTP requests on the specified port. Visit
|
||||
the HTTP url corresponding to the port (typically `http://<host>:<port>/`)
|
||||
in a browser to see the interface.
|
||||
|
||||
# Details
|
||||
|
||||
The objective of pprof is to generate a report for a profile. The report is
|
||||
generated from a location hierarchy, which is reconstructed from the profile
|
||||
samples. Each location contains two values: *flat* is the value of the location
|
||||
itself, while *cum* is the value of the location plus all its
|
||||
descendants. Samples that include a location multiple times (eg for recursive
|
||||
functions) are counted only once per location.
|
||||
|
||||
## Options
|
||||
|
||||
*options* configure the contents of a report. Each option has a value,
|
||||
which can be boolean, numeric, or strings. While only one format can
|
||||
be specified, most options can be selected independently of each
|
||||
other.
|
||||
|
||||
Some common pprof options are:
|
||||
|
||||
* **-flat [default]:** Sort entries based on their flat weight, on text reports.
|
||||
* **-cum:** Sort entries based on cumulative weight, on text reports.
|
||||
* **-functions [default]:** Accumulate samples at the function level; profile
|
||||
locations that describe the same function will be merged into a report entry.
|
||||
* **-lines:** Accumulate samples at the source line level; profile locations that
|
||||
describe the same function will be merged into a report entry.
|
||||
* **-addresses:** Accumulate samples at the instruction address; profile locations
|
||||
that describe the same function address will be merged into a report entry.
|
||||
* **-nodecount= _int_:** Maximum number of entries in the report. pprof will only print
|
||||
this many entries and will use heuristics to select which entries to trim.
|
||||
* **-focus= _regex_:** Only include samples that include a report entry matching
|
||||
*regex*.
|
||||
* **-ignore= _regex_:** Do not include samples that include a report entry matching
|
||||
*regex*.
|
||||
* **-show\_from= _regex_:** Do not show entries above the first one that
|
||||
matches *regex*.
|
||||
* **-show= _regex_:** Only show entries that match *regex*.
|
||||
* **-hide= _regex_:** Do not show entries that match *regex*.
|
||||
|
||||
Each sample in a profile may include multiple values, representing different
|
||||
entities associated to the sample. pprof reports include a single sample value,
|
||||
which by convention is the last one specified in the report. The `sample_index=`
|
||||
option selects which value to use, and can be set to a number (from 0 to the
|
||||
number of values - 1) or the name of the sample value.
|
||||
|
||||
Sample values are numeric values associated to a unit. If pprof can recognize
|
||||
these units, it will attempt to scale the values to a suitable unit for
|
||||
visualization. The `unit=` option will force the use of a specific unit. For
|
||||
example, `unit=sec` will force any time values to be reported in
|
||||
seconds. pprof recognizes most common time and memory size units.
|
||||
|
||||
## Tag filtering
|
||||
|
||||
Samples in a profile may have tags. These tags have a name and a value; this
|
||||
value can be either numeric or a string. pprof can select samples from a
|
||||
profile based on these tags using the `-tagfocus` and `-tagignore` options.
|
||||
|
||||
Generally, these options work as follows:
|
||||
* **-tagfocus=_regex_** or **-tagfocus=_range_:** Restrict to samples with tags
|
||||
matched by regexp or in range.
|
||||
* **-tagignore=_regex_** or **-tagignore=_range_:** Discard samples with tags
|
||||
matched by regexp or in range.
|
||||
|
||||
When using `-tagfocus=regex` and `-tagignore=regex`, the regex will be compared
|
||||
to each value associated with each tag. If one specifies a value
|
||||
like `regex1,regex2`, then only samples with a tag value matching `regex1`
|
||||
and a tag value matching `regex2` will be kept.
|
||||
|
||||
In addition to being able to filter on tag values, one can specify the name of
|
||||
the tag which a certain value must be associated with using the notation
|
||||
`-tagfocus=tagName=value`. Here, the `tagName` must match the tag's name
|
||||
exactly, and the value can be either a regex or a range. If one specifies
|
||||
a value like `regex1,regex2`, then samples with a tag value (paired with the
|
||||
specified tag name) matching either `regex1` or matching `regex2` will match.
|
||||
|
||||
Here are examples explaining how `tagfocus` can be used:
|
||||
|
||||
* `-tagfocus 128kb:512kb` accepts a sample iff it has any numeric tag with
|
||||
memory value in the specified range.
|
||||
* `-tagfocus mytag=128kb:512kb` accepts a sample iff it has a numeric tag
|
||||
`mytag` with memory value in the specified range. There isn't a way to say
|
||||
`-tagfocus mytag=128kb:512kb,16kb:32kb`
|
||||
or `-tagfocus mytag=128kb:512kb,mytag2=128kb:512kb`. Just single value or
|
||||
range for numeric tags.
|
||||
* `-tagfocus someregex` accepts a sample iff it has any string tag with
|
||||
`tagName:tagValue` string matching specified regexp. In the future, this
|
||||
will change to accept sample iff it has any string tag with `tagValue` string
|
||||
matching specified regexp.
|
||||
* `-tagfocus mytag=myvalue1,myvalue2` matches if either of the two tag values
|
||||
are present.
|
||||
|
||||
`-tagignore` works similarly, except that it discards matching samples, instead
|
||||
of keeping them.
|
||||
|
||||
If both the `-tagignore` and `-tagfocus` expressions (either a regexp or a
|
||||
range) match a given sample, then the sample will be discarded.
|
||||
|
||||
## Text reports
|
||||
|
||||
pprof text reports show the location hierarchy in text format.
|
||||
|
||||
* **-text:** Prints the location entries, one per line, including the flat and cum
|
||||
values.
|
||||
* **-tree:** Prints each location entry with its predecessors and successors.
|
||||
* **-peek= _regex_:** Print the location entry with all its predecessors and
|
||||
successors, without trimming any entries.
|
||||
* **-traces:** Prints each sample with a location per line.
|
||||
|
||||
## Graphical reports
|
||||
|
||||
pprof can generate graphical reports on the DOT format, and convert them to
|
||||
multiple formats using the graphviz package.
|
||||
|
||||
These reports represent the location hierarchy as a graph, with a report entry
|
||||
represented as a node. Solid edges represent a direct connection between
|
||||
entries, while dotted edges represent a connection where some intermediate nodes
|
||||
have been removed. Nodes are removed using heuristics to limit the size of
|
||||
the graph, controlled by the *nodecount* option.
|
||||
|
||||
The size of each node represents the flat weight of the node, and the width of
|
||||
each edge represents the cumulative weight of all samples going through
|
||||
it. Nodes are colored according to their cumulative weight, highlighting the
|
||||
paths with the highest cum weight.
|
||||
|
||||
* **-dot:** Generates a report in .dot format. All other formats are generated from
|
||||
this one.
|
||||
* **-svg:** Generates a report in SVG format.
|
||||
* **-web:** Generates a report in SVG format on a temp file, and starts a web
|
||||
browser to view it.
|
||||
* **-png, -jpg, -gif, -pdf:** Generates a report in these formats,
|
||||
|
||||
## Annotated code
|
||||
|
||||
pprof can also generate reports of annotated source with samples associated to
|
||||
them. For these, the source or binaries must be locally available, and the
|
||||
profile must contain data with the appropriate level of detail.
|
||||
|
||||
pprof will look for source files on its current working directory and all its
|
||||
ancestors. pprof will look for binaries on the directories specified in the
|
||||
`$PPROF_BINARY_PATH` environment variable, by default `$HOME/pprof/binaries`
|
||||
(`%USERPROFILE%\pprof\binaries` on Windows). It will look binaries up by name,
|
||||
and if the profile includes linker build ids, it will also search for them in
|
||||
a directory named as the build id.
|
||||
|
||||
pprof uses the binutils tools to examine and disassemble the binaries. By
|
||||
default it will search for those tools in the current path, but it can also
|
||||
search for them in a directory pointed to by the environment variable
|
||||
`$PPROF_TOOLS`.
|
||||
|
||||
* **-disasm= _regex_:** Generates an annotated source listing for functions matching
|
||||
regex, with flat/cum weights for each source line.
|
||||
* **-list= _regex_:** Generates an annotated disassembly listing for functions
|
||||
matching *regex*.
|
||||
* **-weblist= _regex_:** Generates a source/assembly combined annotated listing for
|
||||
functions matching *regex*, and starts a web browser to display it.
|
||||
|
||||
# Fetching profiles
|
||||
|
||||
pprof can read profiles from a file or directly from a URL over http. Its native
|
||||
format is a gzipped profile.proto file, but it can also accept some legacy
|
||||
formats generated by [gperftools](https://github.com/gperftools/gperftools).
|
||||
|
||||
When fetching from a URL handler, pprof accepts options to indicate how much to
|
||||
wait for the profile.
|
||||
|
||||
* **-seconds= _int_:** Makes pprof request for a profile with the specified duration
|
||||
in seconds. Only makes sense for profiles based on elapsed time, such as CPU
|
||||
profiles.
|
||||
* **-timeout= _int_:** Makes pprof wait for the specified timeout when retrieving a
|
||||
profile over http. If not specified, pprof will use heuristics to determine a
|
||||
reasonable timeout.
|
||||
|
||||
If multiple profiles are specified, pprof will fetch them all and merge
|
||||
them. This is useful to combine profiles from multiple processes of a
|
||||
distributed job. The profiles may be from different programs but must be
|
||||
compatible (for example, CPU profiles cannot be combined with heap profiles).
|
||||
|
||||
pprof can subtract a profile from another in order to compare them. For that,
|
||||
use the **-base= _profile_** option, where *profile* is the filename or URL for the
|
||||
profile to be subtracted. This may result on some report entries having negative
|
||||
values.
|
||||
|
||||
## Symbolization
|
||||
|
||||
pprof can add symbol information to a profile that was collected only with
|
||||
address information. This is useful for profiles for compiled languages, where
|
||||
it may not be easy or even possible for the profile source to include function
|
||||
names or source coordinates.
|
||||
|
||||
pprof can extract the symbol information locally by examining the binaries using
|
||||
the binutils tools, or it can ask running jobs that provide a symbolization
|
||||
interface.
|
||||
|
||||
pprof will attempt symbolizing profiles by default, and its `-symbolize` option
|
||||
provides some control over symbolization:
|
||||
|
||||
* **-symbolize=none:** Disables any symbolization from pprof.
|
||||
|
||||
* **-symbolize=local:** Only attempts symbolizing the profile from local
|
||||
binaries using the binutils tools.
|
||||
|
||||
* **-symbolize=remote:** Only attempts to symbolize running jobs by contacting
|
||||
their symbolization handler.
|
||||
|
||||
For local symbolization, pprof will look for the binaries on the paths specified
|
||||
by the profile, and then it will search for them on the path specified by the
|
||||
environment variable `$PPROF_BINARY_PATH`. Also, the name of the main binary can
|
||||
be passed directly to pprof as its first parameter, to override the name or
|
||||
location of the main binary of the profile, like this:
|
||||
|
||||
pprof /path/to/binary profile.pb.gz
|
||||
|
||||
By default pprof will attempt to demangle and simplify C++ names, to provide
|
||||
readable names for C++ symbols. It will aggressively discard template and
|
||||
function parameters. This can be controlled with the `-symbolize=demangle`
|
||||
option. Note that for remote symbolization mangled names may not be provided by
|
||||
the symbolization handler.
|
||||
|
||||
* **--symbolize=demangle=none:** Do not perform any demangling. Show mangled
|
||||
names if available.
|
||||
|
||||
* **-symbolize=demangle=full:** Demangle, but do not perform any
|
||||
simplification. Show full demangled names if available.
|
||||
|
||||
* **-symbolize=demangle=templates:** Demangle, and trim function parameters, but
|
||||
not template parameters.
|
||||
|
149
src/cmd/vendor/github.com/google/pprof/proto/README.md
generated
vendored
149
src/cmd/vendor/github.com/google/pprof/proto/README.md
generated
vendored
@ -1,149 +0,0 @@
|
||||
This is a description of the profile.proto format.
|
||||
|
||||
# Overview
|
||||
|
||||
Profile.proto is a data representation for profile data. It is independent of
|
||||
the type of data being collected and the sampling process used to collect that
|
||||
data. On disk, it is represented as a gzip-compressed protocol buffer, described
|
||||
at src/proto/profile.proto
|
||||
|
||||
A profile in this context refers to a collection of samples, each one
|
||||
representing measurements performed at a certain point in the life of a job. A
|
||||
sample associates a set of measurement values with a list of locations, commonly
|
||||
representing the program call stack when the sample was taken.
|
||||
|
||||
Tools such as pprof analyze these samples and display this information in
|
||||
multiple forms, such as identifying hottest locations, building graphical call
|
||||
graphs or trees, etc.
|
||||
|
||||
# General structure of a profile
|
||||
|
||||
A profile is represented on a Profile message, which contain the following
|
||||
fields:
|
||||
|
||||
* *sample*: A profile sample, with the values measured and the associated call
|
||||
stack as a list of location ids. Samples with identical call stacks can be
|
||||
merged by adding their respective values, element by element.
|
||||
* *location*: A unique place in the program, commonly mapped to a single
|
||||
instruction address. It has a unique nonzero id, to be referenced from the
|
||||
samples. It contains source information in the form of lines, and a mapping id
|
||||
that points to a binary.
|
||||
* *function*: A program function as defined in the program source. It has a
|
||||
unique nonzero id, referenced from the location lines. It contains a
|
||||
human-readable name for the function (eg a C++ demangled name), a system name
|
||||
(eg a C++ mangled name), the name of the corresponding source file, and other
|
||||
function attributes.
|
||||
* *mapping*: A binary that is part of the program during the profile
|
||||
collection. It has a unique nonzero id, referenced from the locations. It
|
||||
includes details on how the binary was mapped during program execution. By
|
||||
convention the main program binary is the first mapping, followed by any
|
||||
shared libraries.
|
||||
* *string_table*: All strings in the profile are represented as indices into
|
||||
this repeating field. The first string is empty, so index == 0 always
|
||||
represents the empty string.
|
||||
|
||||
# Measurement values
|
||||
|
||||
Measurement values are represented as 64-bit integers. The profile contains an
|
||||
explicit description of each value represented, using a ValueType message, with
|
||||
two fields:
|
||||
|
||||
* *Type*: A human-readable description of the type semantics. For example “cpu”
|
||||
to represent CPU time, “wall” or “time” for wallclock time, or “memory” for
|
||||
bytes allocated.
|
||||
* *Unit*: A human-readable name of the unit represented by the 64-bit integer
|
||||
values. For example, it could be “nanoseconds” or “milliseconds” for a time
|
||||
value, or “bytes” or “megabytes” for a memory size. If this is just
|
||||
representing a number of events, the recommended unit name is “count”.
|
||||
|
||||
A profile can represent multiple measurements per sample, but all samples must
|
||||
have the same number and type of measurements. The actual values are stored in
|
||||
the Sample.value fields, each one described by the corresponding
|
||||
Profile.sample_type field.
|
||||
|
||||
Some profiles have a uniform period that describe the granularity of the data
|
||||
collection. For example, a CPU profile may have a period of 100ms, or a memory
|
||||
allocation profile may have a period of 512kb. Profiles can optionally describe
|
||||
such a value on the Profile.period and Profile.period_type fields. The profile
|
||||
period is meant for human consumption and does not affect the interpretation of
|
||||
the profiling data.
|
||||
|
||||
By convention, the first value on all profiles is the number of samples
|
||||
collected at this call stack, with unit “count”. Because the profile does not
|
||||
describe the sampling process beyond the optional period, it must include
|
||||
unsampled values for all measurements. For example, a CPU profile could have
|
||||
value[0] == samples, and value[1] == time in milliseconds.
|
||||
|
||||
## Locations, functions and mappings
|
||||
|
||||
Each sample lists the id of each location where the sample was collected, in
|
||||
bottom-up order. Each location has an explicit unique nonzero integer id,
|
||||
independent of its position in the profile, and holds additional information to
|
||||
identify the corresponding source.
|
||||
|
||||
The profile source is expected to perform any adjustment required to the
|
||||
locations in order to point to the calls in the stack. For example, if the
|
||||
profile source extracts the call stack by walking back over the program stack,
|
||||
it must adjust the instruction addresses to point to the actual call
|
||||
instruction, instead of the instruction that each call will return to.
|
||||
|
||||
Sources usually generate profiles that fall into these two categories:
|
||||
|
||||
* *Unsymbolized profiles*: These only contain instruction addresses, and are to
|
||||
be symbolized by a separate tool. It is critical for each location to point to
|
||||
a valid mapping, which will provide the information required for
|
||||
symbolization. These are used for profiles of compiled languages, such as C++
|
||||
and Go.
|
||||
|
||||
* *Symbolized profiles*: These contain all the symbol information available for
|
||||
the profile. Mappings and instruction addresses are optional for symbolized
|
||||
locations. These are used for profiles of interpreted or jitted languages,
|
||||
such as Java or Python. Also, the profile format allows the generation of
|
||||
mixed profiles, with symbolized and unsymbolized locations.
|
||||
|
||||
The symbol information is represented in the repeating lines field of the
|
||||
Location message. A location has multiple lines if it reflects multiple program
|
||||
sources, for example if representing inlined call stacks. Lines reference
|
||||
functions by their unique nonzero id, and the source line number within the
|
||||
source file listed by the function. A function contains the source attributes
|
||||
for a function, including its name, source file, etc. Functions include both a
|
||||
user and a system form of the name, for example to include C++ demangled and
|
||||
mangled names. For profiles where only a single name exists, both should be set
|
||||
to the same string.
|
||||
|
||||
Mappings are also referenced from locations by their unique nonzero id, and
|
||||
include all information needed to symbolize addresses within the mapping. It
|
||||
includes similar information to the Linux /proc/self/maps file. Locations
|
||||
associated to a mapping should have addresses that land between the mapping
|
||||
start and limit. Also, if available, mappings should include a build id to
|
||||
uniquely identify the version of the binary being used.
|
||||
|
||||
## Labels
|
||||
|
||||
Samples optionally contain labels, which are annotations to discriminate samples
|
||||
with identical locations. For example, a label can be used on a malloc profile
|
||||
to indicate allocation size, so two samples on the same call stack with sizes
|
||||
2MB and 4MB do not get merged into a single sample with two allocations and a
|
||||
size of 6MB.
|
||||
|
||||
Labels can be string-based or numeric. They are represented by the Label
|
||||
message, with a key identifying the label and either a string or numeric
|
||||
value. For numeric labels, the measurement unit can be specified in the profile.
|
||||
If no unit is specified and the key is "request" or "alignment",
|
||||
then the units are assumed to be "bytes". Otherwise when no unit is specified
|
||||
the key will be used as the measurement unit of the numeric value. All tags with
|
||||
the same key should have the same unit.
|
||||
|
||||
## Keep and drop expressions
|
||||
|
||||
Some profile sources may have knowledge of locations that are uninteresting or
|
||||
irrelevant. However, if symbolization is needed in order to identify these
|
||||
locations, the profile source may not be able to remove them when the profile is
|
||||
generated. The profile format provides a mechanism to identify these frames by
|
||||
name, through regular expressions.
|
||||
|
||||
These expressions must match the function name in its entirety. Frames that
|
||||
match Profile.drop\_frames will be dropped from the profile, along with any
|
||||
frames below it. Frames that match Profile.keep\_frames will be kept, even if
|
||||
they match drop\_frames.
|
||||
|
203
src/cmd/vendor/github.com/google/pprof/proto/profile.proto
generated
vendored
203
src/cmd/vendor/github.com/google/pprof/proto/profile.proto
generated
vendored
@ -1,203 +0,0 @@
|
||||
// Copyright (c) 2016, Google Inc.
|
||||
// All rights reserved.
|
||||
//
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// Profile is a common stacktrace profile format.
|
||||
//
|
||||
// Measurements represented with this format should follow the
|
||||
// following conventions:
|
||||
//
|
||||
// - Consumers should treat unset optional fields as if they had been
|
||||
// set with their default value.
|
||||
//
|
||||
// - When possible, measurements should be stored in "unsampled" form
|
||||
// that is most useful to humans. There should be enough
|
||||
// information present to determine the original sampled values.
|
||||
//
|
||||
// - On-disk, the serialized proto must be gzip-compressed.
|
||||
//
|
||||
// - The profile is represented as a set of samples, where each sample
|
||||
// references a sequence of locations, and where each location belongs
|
||||
// to a mapping.
|
||||
// - There is a N->1 relationship from sample.location_id entries to
|
||||
// locations. For every sample.location_id entry there must be a
|
||||
// unique Location with that id.
|
||||
// - There is an optional N->1 relationship from locations to
|
||||
// mappings. For every nonzero Location.mapping_id there must be a
|
||||
// unique Mapping with that id.
|
||||
|
||||
syntax = "proto3";
|
||||
|
||||
package perftools.profiles;
|
||||
|
||||
option java_package = "com.google.perftools.profiles";
|
||||
option java_outer_classname = "ProfileProto";
|
||||
|
||||
message Profile {
|
||||
// A description of the samples associated with each Sample.value.
|
||||
// For a cpu profile this might be:
|
||||
// [["cpu","nanoseconds"]] or [["wall","seconds"]] or [["syscall","count"]]
|
||||
// For a heap profile, this might be:
|
||||
// [["allocations","count"], ["space","bytes"]],
|
||||
// If one of the values represents the number of events represented
|
||||
// by the sample, by convention it should be at index 0 and use
|
||||
// sample_type.unit == "count".
|
||||
repeated ValueType sample_type = 1;
|
||||
// The set of samples recorded in this profile.
|
||||
repeated Sample sample = 2;
|
||||
// Mapping from address ranges to the image/binary/library mapped
|
||||
// into that address range. mapping[0] will be the main binary.
|
||||
repeated Mapping mapping = 3;
|
||||
// Useful program location
|
||||
repeated Location location = 4;
|
||||
// Functions referenced by locations
|
||||
repeated Function function = 5;
|
||||
// A common table for strings referenced by various messages.
|
||||
// string_table[0] must always be "".
|
||||
repeated string string_table = 6;
|
||||
// frames with Function.function_name fully matching the following
|
||||
// regexp will be dropped from the samples, along with their successors.
|
||||
int64 drop_frames = 7; // Index into string table.
|
||||
// frames with Function.function_name fully matching the following
|
||||
// regexp will be kept, even if it matches drop_functions.
|
||||
int64 keep_frames = 8; // Index into string table.
|
||||
|
||||
// The following fields are informational, do not affect
|
||||
// interpretation of results.
|
||||
|
||||
// Time of collection (UTC) represented as nanoseconds past the epoch.
|
||||
int64 time_nanos = 9;
|
||||
// Duration of the profile, if a duration makes sense.
|
||||
int64 duration_nanos = 10;
|
||||
// The kind of events between sampled ocurrences.
|
||||
// e.g [ "cpu","cycles" ] or [ "heap","bytes" ]
|
||||
ValueType period_type = 11;
|
||||
// The number of events between sampled occurrences.
|
||||
int64 period = 12;
|
||||
// Freeform text associated to the profile.
|
||||
repeated int64 comment = 13; // Indices into string table.
|
||||
// Index into the string table of the type of the preferred sample
|
||||
// value. If unset, clients should default to the last sample value.
|
||||
int64 default_sample_type = 14;
|
||||
}
|
||||
|
||||
// ValueType describes the semantics and measurement units of a value.
|
||||
message ValueType {
|
||||
int64 type = 1; // Index into string table.
|
||||
int64 unit = 2; // Index into string table.
|
||||
}
|
||||
|
||||
// Each Sample records values encountered in some program
|
||||
// context. The program context is typically a stack trace, perhaps
|
||||
// augmented with auxiliary information like the thread-id, some
|
||||
// indicator of a higher level request being handled etc.
|
||||
message Sample {
|
||||
// The ids recorded here correspond to a Profile.location.id.
|
||||
// The leaf is at location_id[0].
|
||||
repeated uint64 location_id = 1;
|
||||
// The type and unit of each value is defined by the corresponding
|
||||
// entry in Profile.sample_type. All samples must have the same
|
||||
// number of values, the same as the length of Profile.sample_type.
|
||||
// When aggregating multiple samples into a single sample, the
|
||||
// result has a list of values that is the elemntwise sum of the
|
||||
// lists of the originals.
|
||||
repeated int64 value = 2;
|
||||
// label includes additional context for this sample. It can include
|
||||
// things like a thread id, allocation size, etc
|
||||
repeated Label label = 3;
|
||||
}
|
||||
|
||||
message Label {
|
||||
int64 key = 1; // Index into string table
|
||||
|
||||
// At most one of the following must be present
|
||||
int64 str = 2; // Index into string table
|
||||
int64 num = 3;
|
||||
|
||||
// Should only be present when num is present.
|
||||
// Specifies the units of num.
|
||||
// Use arbitrary string (for example, "requests") as a custom count unit.
|
||||
// If no unit is specified, consumer may apply heuristic to deduce the unit.
|
||||
// Consumers may also interpret units like "bytes" and "kilobytes" as memory
|
||||
// units and units like "seconds" and "nanoseconds" as time units,
|
||||
// and apply appropriate unit conversions to these.
|
||||
int64 num_unit = 4; // Index into string table
|
||||
}
|
||||
|
||||
message Mapping {
|
||||
// Unique nonzero id for the mapping.
|
||||
uint64 id = 1;
|
||||
// Address at which the binary (or DLL) is loaded into memory.
|
||||
uint64 memory_start = 2;
|
||||
// The limit of the address range occupied by this mapping.
|
||||
uint64 memory_limit = 3;
|
||||
// Offset in the binary that corresponds to the first mapped address.
|
||||
uint64 file_offset = 4;
|
||||
// The object this entry is loaded from. This can be a filename on
|
||||
// disk for the main binary and shared libraries, or virtual
|
||||
// abstractions like "[vdso]".
|
||||
int64 filename = 5; // Index into string table
|
||||
// A string that uniquely identifies a particular program version
|
||||
// with high probability. E.g., for binaries generated by GNU tools,
|
||||
// it could be the contents of the .note.gnu.build-id field.
|
||||
int64 build_id = 6; // Index into string table
|
||||
|
||||
// The following fields indicate the resolution of symbolic info.
|
||||
bool has_functions = 7;
|
||||
bool has_filenames = 8;
|
||||
bool has_line_numbers = 9;
|
||||
bool has_inline_frames = 10;
|
||||
}
|
||||
|
||||
// Describes function and line table debug information.
|
||||
message Location {
|
||||
// Unique nonzero id for the location. A profile could use
|
||||
// instruction addresses or any integer sequence as ids.
|
||||
uint64 id = 1;
|
||||
// The id of the corresponding profile.Mapping for this location.
|
||||
// It can be unset if the mapping is unknown or not applicable for
|
||||
// this profile type.
|
||||
uint64 mapping_id = 2;
|
||||
// The instruction address for this location, if available. It
|
||||
// should be within [Mapping.memory_start...Mapping.memory_limit]
|
||||
// for the corresponding mapping. A non-leaf address may be in the
|
||||
// middle of a call instruction. It is up to display tools to find
|
||||
// the beginning of the instruction if necessary.
|
||||
uint64 address = 3;
|
||||
// Multiple line indicates this location has inlined functions,
|
||||
// where the last entry represents the caller into which the
|
||||
// preceding entries were inlined.
|
||||
//
|
||||
// E.g., if memcpy() is inlined into printf:
|
||||
// line[0].function_name == "memcpy"
|
||||
// line[1].function_name == "printf"
|
||||
repeated Line line = 4;
|
||||
// Provides an indication that multiple symbols map to this location's
|
||||
// address, for example due to identical code folding by the linker. In that
|
||||
// case the line information above represents one of the multiple
|
||||
// symbols. This field must be recomputed when the symbolization state of the
|
||||
// profile changes.
|
||||
bool is_folded = 5;
|
||||
}
|
||||
|
||||
message Line {
|
||||
// The id of the corresponding profile.Function for this line.
|
||||
uint64 function_id = 1;
|
||||
// Line number in source code.
|
||||
int64 line = 2;
|
||||
}
|
||||
|
||||
message Function {
|
||||
// Unique nonzero id for the function.
|
||||
uint64 id = 1;
|
||||
// Name of the function, in human-readable form if available.
|
||||
int64 name = 2; // Index into string table
|
||||
// Name of the function, as identified by the system.
|
||||
// For instance, it can be a C++ mangled name.
|
||||
int64 system_name = 3; // Index into string table
|
||||
// Source file containing the function.
|
||||
int64 filename = 4; // Index into string table
|
||||
// Line number in source file.
|
||||
int64 start_line = 5;
|
||||
}
|
26
src/cmd/vendor/github.com/google/pprof/test.sh
generated
vendored
26
src/cmd/vendor/github.com/google/pprof/test.sh
generated
vendored
@ -1,26 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -e
|
||||
set -x
|
||||
MODE=atomic
|
||||
echo "mode: $MODE" > coverage.txt
|
||||
|
||||
# All packages.
|
||||
PKG=$(go list ./...)
|
||||
|
||||
staticcheck $PKG
|
||||
unused $PKG
|
||||
|
||||
# Packages that have any tests.
|
||||
PKG=$(go list -f '{{if .TestGoFiles}} {{.ImportPath}} {{end}}' ./...)
|
||||
|
||||
go test -v $PKG
|
||||
|
||||
for d in $PKG; do
|
||||
go test -race -coverprofile=profile.out -covermode=$MODE $d
|
||||
if [ -f profile.out ]; then
|
||||
cat profile.out | grep -v "^mode: " >> coverage.txt
|
||||
rm profile.out
|
||||
fi
|
||||
done
|
||||
|
46
src/cmd/vendor/github.com/google/pprof/third_party/update_d3flamegraph.sh
generated
vendored
46
src/cmd/vendor/github.com/google/pprof/third_party/update_d3flamegraph.sh
generated
vendored
@ -1,46 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
set -eu
|
||||
set -o pipefail
|
||||
|
||||
D3FLAMEGRAPH_REPO="https://raw.githubusercontent.com/spiermar/d3-flame-graph"
|
||||
D3FLAMEGRAPH_VERSION="2.0.0-alpha4"
|
||||
D3FLAMEGRAPH_JS="d3-flamegraph.js"
|
||||
D3FLAMEGRAPH_CSS="d3-flamegraph.css"
|
||||
|
||||
cd $(dirname $0)
|
||||
|
||||
D3FLAMEGRAPH_DIR=d3flamegraph
|
||||
|
||||
generate_d3flamegraph_go() {
|
||||
local d3_js=$(curl -s "${D3FLAMEGRAPH_REPO}/${D3FLAMEGRAPH_VERSION}/dist/${D3FLAMEGRAPH_JS}" | sed 's/`/`+"`"+`/g')
|
||||
local d3_css=$(curl -s "${D3FLAMEGRAPH_REPO}/${D3FLAMEGRAPH_VERSION}/dist/${D3FLAMEGRAPH_CSS}")
|
||||
|
||||
cat <<-EOF > $D3FLAMEGRAPH_DIR/d3_flame_graph.go
|
||||
// A D3.js plugin that produces flame graphs from hierarchical data.
|
||||
// https://github.com/spiermar/d3-flame-graph
|
||||
// Version $D3FLAMEGRAPH_VERSION
|
||||
// See LICENSE file for license details
|
||||
|
||||
package d3flamegraph
|
||||
|
||||
// JSSource returns the $D3FLAMEGRAPH_JS file
|
||||
const JSSource = \`
|
||||
$d3_js
|
||||
\`
|
||||
|
||||
// CSSSource returns the $D3FLAMEGRAPH_CSS file
|
||||
const CSSSource = \`
|
||||
$d3_css
|
||||
\`
|
||||
EOF
|
||||
gofmt -w $D3FLAMEGRAPH_DIR/d3_flame_graph.go
|
||||
}
|
||||
|
||||
get_license() {
|
||||
curl -s -o $D3FLAMEGRAPH_DIR/LICENSE "${D3FLAMEGRAPH_REPO}/${D3FLAMEGRAPH_VERSION}/LICENSE"
|
||||
}
|
||||
|
||||
mkdir -p $D3FLAMEGRAPH_DIR
|
||||
get_license
|
||||
generate_d3flamegraph_go
|
13
src/cmd/vendor/github.com/ianlancetaylor/demangle/.gitignore
generated
vendored
13
src/cmd/vendor/github.com/ianlancetaylor/demangle/.gitignore
generated
vendored
@ -1,13 +0,0 @@
|
||||
*.o
|
||||
*.a
|
||||
*.so
|
||||
._*
|
||||
.nfs.*
|
||||
a.out
|
||||
*~
|
||||
*.orig
|
||||
*.rej
|
||||
*.exe
|
||||
.*.swp
|
||||
core
|
||||
demangle.test
|
144
src/cmd/vendor/github.com/ianlancetaylor/demangle/c++filt.go
generated
vendored
144
src/cmd/vendor/github.com/ianlancetaylor/demangle/c++filt.go
generated
vendored
@ -1,144 +0,0 @@
|
||||
// Copyright 2015 The Go Authors. All rights reserved.
|
||||
// Use of this source code is governed by a BSD-style
|
||||
// license that can be found in the LICENSE file.
|
||||
|
||||
// +build ignore
|
||||
|
||||
// This is a program that works like the GNU c++filt program.
|
||||
// It's here for testing purposes and as an example.
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"bufio"
|
||||
"flag"
|
||||
"fmt"
|
||||
"io"
|
||||
"os"
|
||||
"strings"
|
||||
"unicode"
|
||||
|
||||
"github.com/ianlancetaylor/demangle"
|
||||
)
|
||||
|
||||
func flagUsage() {
|
||||
usage(os.Stderr, 2)
|
||||
}
|
||||
|
||||
func usage(w io.Writer, status int) {
|
||||
fmt.Fprintf(w, "Usage: %s [options] [mangled names]\n", os.Args[0])
|
||||
flag.CommandLine.SetOutput(w)
|
||||
flag.PrintDefaults()
|
||||
fmt.Fprintln(w, `Demangled names are displayed to stdout
|
||||
If a name cannot be demangled it is just echoed to stdout.
|
||||
If no names are provided on the command line, stdin is read.`)
|
||||
os.Exit(status)
|
||||
}
|
||||
|
||||
var stripUnderscore = flag.Bool("_", false, "Ignore first leading underscore")
|
||||
var noParams = flag.Bool("p", false, "Do not display function argument types")
|
||||
var noVerbose = flag.Bool("i", false, "Do not show implementation details (if any)")
|
||||
var help = flag.Bool("h", false, "Display help information")
|
||||
var debug = flag.Bool("d", false, "Display debugging information for strings on command line")
|
||||
|
||||
// Unimplemented c++filt flags:
|
||||
// -n (opposite of -_)
|
||||
// -t (demangle types)
|
||||
// -s (set demangling style)
|
||||
// -V (print version information)
|
||||
|
||||
// Characters considered to be part of a symbol.
|
||||
const symbolChars = "_$."
|
||||
|
||||
func main() {
|
||||
flag.Usage = func() { usage(os.Stderr, 1) }
|
||||
flag.Parse()
|
||||
|
||||
if *help {
|
||||
usage(os.Stdout, 0)
|
||||
}
|
||||
|
||||
out := bufio.NewWriter(os.Stdout)
|
||||
|
||||
if flag.NArg() > 0 {
|
||||
for _, f := range flag.Args() {
|
||||
if *debug {
|
||||
a, err := demangle.ToAST(f, options()...)
|
||||
if err != nil {
|
||||
fmt.Fprintf(os.Stderr, "%s: %v\n", f, err)
|
||||
} else {
|
||||
fmt.Fprintf(out, "%#v\n", a)
|
||||
}
|
||||
} else {
|
||||
doDemangle(out, f)
|
||||
}
|
||||
out.WriteByte('\n')
|
||||
}
|
||||
if err := out.Flush(); err != nil {
|
||||
fmt.Fprintln(os.Stderr, err)
|
||||
os.Exit(2)
|
||||
}
|
||||
return
|
||||
}
|
||||
|
||||
scanner := bufio.NewScanner(bufio.NewReader(os.Stdin))
|
||||
for scanner.Scan() {
|
||||
line := scanner.Text()
|
||||
start := -1
|
||||
for i, c := range line {
|
||||
if unicode.IsLetter(c) || unicode.IsNumber(c) || strings.ContainsRune(symbolChars, c) {
|
||||
if start < 0 {
|
||||
start = i
|
||||
}
|
||||
} else {
|
||||
if start >= 0 {
|
||||
doDemangle(out, line[start:i])
|
||||
}
|
||||
out.WriteRune(c)
|
||||
start = -1
|
||||
}
|
||||
}
|
||||
if start >= 0 {
|
||||
doDemangle(out, line[start:])
|
||||
start = -1
|
||||
}
|
||||
out.WriteByte('\n')
|
||||
if err := out.Flush(); err != nil {
|
||||
fmt.Fprintln(os.Stderr, err)
|
||||
os.Exit(2)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Demangle a string just as the GNU c++filt program does.
|
||||
func doDemangle(out *bufio.Writer, name string) {
|
||||
skip := 0
|
||||
if name[0] == '.' || name[0] == '$' {
|
||||
skip++
|
||||
}
|
||||
if *stripUnderscore && name[skip] == '_' {
|
||||
skip++
|
||||
}
|
||||
result := demangle.Filter(name[skip:], options()...)
|
||||
if result == name[skip:] {
|
||||
out.WriteString(name)
|
||||
} else {
|
||||
if name[0] == '.' {
|
||||
out.WriteByte('.')
|
||||
}
|
||||
out.WriteString(result)
|
||||
}
|
||||
}
|
||||
|
||||
// options returns the demangling options to use based on the command
|
||||
// line flags.
|
||||
func options() []demangle.Option {
|
||||
var options []demangle.Option
|
||||
if *noParams {
|
||||
options = append(options, demangle.NoParams)
|
||||
}
|
||||
if !*noVerbose {
|
||||
options = append(options, demangle.Verbose)
|
||||
}
|
||||
return options
|
||||
}
|
133
src/cmd/vendor/vendor.json
vendored
133
src/cmd/vendor/vendor.json
vendored
@ -1,40 +1,123 @@
|
||||
{
|
||||
"comment": "",
|
||||
"ignore": "",
|
||||
"package": [
|
||||
{
|
||||
"canonical": "github.com/ianlancetaylor/demangle",
|
||||
"local": "github.com/ianlancetaylor/demangle",
|
||||
"checksumSHA1": "G9UsR+iruMWxwUefhy+ID+VIFNs=",
|
||||
"path": "github.com/google/pprof/driver",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "LzGfApA19baVJIbQEqziWpRS3zE=",
|
||||
"path": "github.com/google/pprof/internal/binutils",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "f7aprpcWR7iZX1PJgKBZrpt++XY=",
|
||||
"path": "github.com/google/pprof/internal/driver",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "IhuyU2pFSHhQxzadDBw1nHbcsrY=",
|
||||
"path": "github.com/google/pprof/internal/elfexec",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "8vah+aXLGpbtn55JR8MkCAEOMrk=",
|
||||
"path": "github.com/google/pprof/internal/graph",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "QPWfnT5pEU2jOOb8l8hpiFzQJ7Q=",
|
||||
"path": "github.com/google/pprof/internal/measurement",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "PWZdFtGfGz/zbQTfvel9737NZdY=",
|
||||
"path": "github.com/google/pprof/internal/plugin",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "LmDglu/S6vFmgqkxubKDZemFHaY=",
|
||||
"path": "github.com/google/pprof/internal/proftest",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "gdyWnzbjgwmqJ2EN/WAp+QPu7d0=",
|
||||
"path": "github.com/google/pprof/internal/report",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "rWdirHgJi1+TdRwv5v3zjgFKcJA=",
|
||||
"path": "github.com/google/pprof/internal/symbolizer",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "5lS2AF207MVYyjF+82qHkWK2V64=",
|
||||
"path": "github.com/google/pprof/internal/symbolz",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "RvwtpZ+NVtPRCo4EiFvLFFHpoBo=",
|
||||
"path": "github.com/google/pprof/profile",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "xmqfYca88U2c/I4642r3ps9uIRg=",
|
||||
"path": "github.com/google/pprof/third_party/d3",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "LzWzD56Trzpq+0hLR00Yw5Gpepw=",
|
||||
"path": "github.com/google/pprof/third_party/d3flamegraph",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "738v1E0v0qRW6oAKdCpBEtyVNnY=",
|
||||
"path": "github.com/google/pprof/third_party/svgpan",
|
||||
"revision": "4d67f66d7c9469639518a80f378434bb7e9156b7",
|
||||
"revisionTime": "2018-05-09T15:07:09Z"
|
||||
},
|
||||
{
|
||||
"checksumSHA1": "UDJQBwUTuQYEHHJ/D7nPBv1qNqI=",
|
||||
"path": "github.com/ianlancetaylor/demangle",
|
||||
"revision": "4883227f66371e02c4948937d3e2be1664d9be38",
|
||||
"revisionTime": "2016-09-27T19:13:59Z"
|
||||
},
|
||||
{
|
||||
"canonical": "github.com/google/pprof",
|
||||
"local": "github.com/google/pprof",
|
||||
"revision": "520140b6bf47519c766e8380e5f094576347b016",
|
||||
"revisionTime": "2018-05-08T15:00:43Z"
|
||||
},
|
||||
{
|
||||
"canonical": "golang.org/x/arch/x86/x86asm",
|
||||
"local": "golang.org/x/arch/x86/x86asm",
|
||||
"path": "golang.org/x/arch/arm/armasm",
|
||||
"revision": "5099b4b992f2813e39cfe2623c6f638718bd0fc6",
|
||||
"revisionTime": "2018-04-06T10:28:20Z"
|
||||
},
|
||||
{
|
||||
"canonical": "golang.org/x/arch/arm/armasm",
|
||||
"local": "golang.org/x/arch/arm/armasm",
|
||||
"revision": "5099b4b992f2813e39cfe2623c6f638718bd0fc6",
|
||||
"revisionTime": "2018-04-06T10:28:20Z"
|
||||
},
|
||||
{
|
||||
"canonical": "golang.org/x/arch/ppc64/ppc64asm",
|
||||
"local": "golang.org/x/arch/ppc64/ppc64asm",
|
||||
"revision": "5099b4b992f2813e39cfe2623c6f638718bd0fc6",
|
||||
"revisionTime": "2018-04-06T10:28:20Z"
|
||||
},
|
||||
{
|
||||
"canonical": "golang.org/x/arch/arm64/arm6464asm",
|
||||
"local": "golang.org/x/arch/arm64/arm64asm",
|
||||
"path": "golang.org/x/arch/arm64/arm64asm",
|
||||
"revision": "9111c30535f37e70dcaf5956d34b03233f90f3b6",
|
||||
"revisionTime": "2018-03-13T04:07:09Z"
|
||||
},
|
||||
{
|
||||
"path": "golang.org/x/arch/ppc64/ppc64asm",
|
||||
"revision": "5099b4b992f2813e39cfe2623c6f638718bd0fc6",
|
||||
"revisionTime": "2018-04-06T10:28:20Z"
|
||||
},
|
||||
{
|
||||
"path": "golang.org/x/arch/x86/x86asm",
|
||||
"revision": "5099b4b992f2813e39cfe2623c6f638718bd0fc6",
|
||||
"revisionTime": "2018-04-06T10:28:20Z"
|
||||
}
|
||||
]
|
||||
],
|
||||
"rootPath": "/cmd"
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user