diff options
| author | Walter Erquinigo <wallace@fb.com> | 2022-06-14 19:05:30 -0700 |
|---|---|---|
| committer | Walter Erquinigo <wallace@fb.com> | 2022-06-16 11:42:22 -0700 |
| commit | 9f45f23d860251edceed6128110855c51af4f39f (patch) | |
| tree | 0fc6d20585ccaa76a5c37ec92f0161a2bdfcb6f4 /lldb/docs | |
| parent | 6a5355e8a159bd9c058d4fbba2a87e0465fe0dc7 (diff) | |
| download | llvm-9f45f23d860251edceed6128110855c51af4f39f.tar.gz | |
[trace][intelpt] Support system-wide tracing [21] - Support long numbers in JSON
llvm's JSON parser supports 64 bit integers, but other tools like the
ones written in JS don't support numbers that big, so we need to
represent these possibly big numbers as a string. This diff uses that to
represent addresses and tsc zero. The former is printed in hex for and
the latter in decimal string form. The schema was updated mentioning
that.
Besides that, I fixed some remaining issues and now all test pass. Before I wasn't running all tests because for some reason my computer reverted perf_paranoid to 1.
Differential Revision: https://reviews.llvm.org/D127819
Diffstat (limited to 'lldb/docs')
| -rw-r--r-- | lldb/docs/lldb-gdb-remote.txt | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/lldb/docs/lldb-gdb-remote.txt b/lldb/docs/lldb-gdb-remote.txt index 4f0cfa4585b0..d0f069a5c7a9 100644 --- a/lldb/docs/lldb-gdb-remote.txt +++ b/lldb/docs/lldb-gdb-remote.txt @@ -299,14 +299,14 @@ read packet: {"name":<name>, "description":<description>}/E<error code>;AAAAAAAA // intel-pt supports both "thread tracing" and "process tracing". // // "Process tracing" is implemented in two different ways. If the -// "perCoreTracing" option is false, then each thread is traced individually +// "perCpuTracing" option is false, then each thread is traced individually // but managed by the same "process trace" instance. This means that the // amount of trace buffers used is proportional to the number of running // threads. This is the recommended option unless the number of threads is -// huge. If "perCoreTracing" is true, then each cpu core is traced invidually +// huge. If "perCpuTracing" is true, then each cpu core is traced invidually // instead of each thread, which uses a fixed number of trace buffers, but // might result in less data available for less frequent threads. See -// "perCoreTracing" below for more information. +// "perCpuTracing" below for more information. // // Each actual intel pt trace buffer, either from "process tracing" or "thread // tracing", is stored in an in-memory circular buffer, which keeps the most @@ -352,7 +352,7 @@ read packet: {"name":<name>, "description":<description>}/E<error code>;AAAAAAAA // 0 if supported. // // /* process tracing only */ -// "perCoreTracing": <boolean> +// "perCpuTracing": <boolean> // Instead of having an individual trace buffer per thread, this option // triggers the collection on a per cpu core basis. This effectively // traces the entire activity on all cores. At decoding time, in order @@ -374,13 +374,13 @@ read packet: {"name":<name>, "description":<description>}/E<error code>;AAAAAAAA // buffers for the current process, excluding the ones started with // "thread tracing". // -// If "perCoreTracing" is false, whenever a thread is attempted to be +// If "perCpuTracing" is false, whenever a thread is attempted to be // traced due to "process tracing" and the limit would be reached, the // process is stopped with a "tracing" reason along with a meaningful // description, so that the user can retrace the process if needed. // -// If "perCoreTracing" is true, then starting the system-wide trace -// session fails if all the individual per-core trace buffers require +// If "perCpuTracing" is true, then starting the system-wide trace +// session fails if all the individual per-cpu trace buffers require // in total more memory that the limit impossed by this parameter. // } // |