forked from OSchip/llvm-project
Tidy some language in the xray documentation.
llvm-svn: 333354
This commit is contained in:
parent
59949471c9
commit
66c5bbc53e
|
@ -48,11 +48,11 @@ Getting Traces
|
|||
--------------
|
||||
|
||||
By default, XRay does not write out the trace files or patch the application
|
||||
before main starts. If we just run ``llc`` it should just work like a normally
|
||||
built binary. However, if we want to get a full trace of the application's
|
||||
operations (of the functions we do end up instrumenting with XRay) then we need
|
||||
to enable XRay at application start. To do this, XRay checks the
|
||||
``XRAY_OPTIONS`` environment variable.
|
||||
before main starts. If we run ``llc`` it should work like a normally built
|
||||
binary. If we want to get a full trace of the application's operations (of the
|
||||
functions we do end up instrumenting with XRay) then we need to enable XRay
|
||||
at application start. To do this, XRay checks the ``XRAY_OPTIONS`` environment
|
||||
variable.
|
||||
|
||||
::
|
||||
|
||||
|
@ -73,9 +73,8 @@ instrumented, and how much time we're spending in parts of the code. To make
|
|||
sense of this data, we use the ``llvm-xray`` tool which has a few subcommands
|
||||
to help us understand our trace.
|
||||
|
||||
One of the simplest things we can do is to get an accounting of the functions
|
||||
that have been instrumented. We can see an example accounting with ``llvm-xray
|
||||
account``:
|
||||
One of the things we can do is to get an accounting of the functions that have
|
||||
been instrumented. We can see an example accounting with ``llvm-xray account``:
|
||||
|
||||
::
|
||||
|
||||
|
@ -202,8 +201,7 @@ Given a trace, and optionally an instrumentation map, the ``llvm-xray stack``
|
|||
command can be used to analyze a call stack graph constructed from the function
|
||||
call timeline.
|
||||
|
||||
The simplest way to use the command is simply to output the top stacks by call
|
||||
count and time spent.
|
||||
The way to use the command is to output the top stacks by call count and time spent.
|
||||
|
||||
::
|
||||
|
||||
|
@ -245,7 +243,7 @@ FlameGraph tool, currently available on `github
|
|||
|
||||
To generate output for a flamegraph, a few more options are necessary.
|
||||
|
||||
- ``-all-stacks`` - Emits all of the stacks instead of just the top stacks.
|
||||
- ``-all-stacks`` - Emits all of the stacks.
|
||||
- ``-stack-format`` - Choose the flamegraph output format 'flame'.
|
||||
- ``-aggregation-type`` - Choose the metric to graph.
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ When gathering XRay traces in Flight Data Recorder mode, each thread of an
|
|||
application will claim buffers to fill with trace data, which at some point
|
||||
is finalized and flushed.
|
||||
|
||||
A goal of the profiler is to minimize overhead, so the flushed data directly
|
||||
A goal of the profiler is to minimize overhead, the flushed data directly
|
||||
corresponds to the buffer.
|
||||
|
||||
This document describes the format of a trace file.
|
||||
|
@ -106,11 +106,11 @@ There are a few categories of data in the sequence.
|
|||
- ``Function Arguments``: The arguments to some functions are included in the
|
||||
trace. These are either pointer addresses or primitives that are read and
|
||||
logged independently of their types in a high level language. To the tracer,
|
||||
they are all simply numbers. Function Records that have attached arguments
|
||||
will indicate their presence on the function entry record. We only support
|
||||
logging contiguous function argument sequences starting with argument zero,
|
||||
which will be the "this" pointer for member function invocations. For example,
|
||||
we don't support logging the first and third argument.
|
||||
they are all numbers. Function Records that have attached arguments will
|
||||
indicate their presence on the function entry record. We only support logging
|
||||
contiguous function argument sequences starting with argument zero, which will
|
||||
be the "this" pointer for member function invocations. For example, we don't
|
||||
support logging the first and third argument.
|
||||
|
||||
A reader of the memory format must maintain a state machine. The format makes no
|
||||
attempt to pad for alignment, and it is not seekable.
|
||||
|
|
Loading…
Reference in New Issue