forked from OSchip/llvm-project
48d8af9825
As mentioned in the comment inside the code, the Intel documentation states that the internal CPU buffer is flushed out to RAM only when tracing is disabled. Otherwise, the buffer on RAM might be stale. This diff disables tracing when the trace buffer is going to be read. This is a quite safe operation, as the reading is done when the inferior is paused at a breakpoint, so we are not losing any packets because there's no code being executed. After the reading is finished, tracing is enabled back. It's a bit hard to write a test for this now, but Greg Clayton and I will refactor the PT support and writing tests for it will be easier. However I tested it manually by doing a script that automates the following flow ``` (lldb) b main Breakpoint 1: where = a.out`main + 15 at main.cpp:4:7, address = 0x000000000040050f (lldb) r Process 3078226 stopped * thread #1, name = 'a.out', stop reason = breakpoint 1.1 frame #0: 0x000000000040050f a.out`main at main.cpp:4:7 (lldb) processor-trace start (lldb) b 5 Breakpoint 2: where = a.out`main + 22 at main.cpp:5:12, address = 0x0000000000400516 (lldb) c Process 3078226 resuming Process 3078226 stopped * thread #1, name = 'a.out', stop reason = breakpoint 2.1 frame #0: 0x0000000000400516 a.out`main at main.cpp:5:12 (lldb) processor-trace show-instr-log thread #1: tid=3078226 0x40050f <+15>: movl $0x0, -0x8(%rbp) >>> Before, some runs of the script up to this point lead to empty traces (lldb) b 6 Breakpoint 3: where = a.out`main + 42 at main.cpp:6:14, address = 0x000000000040052a (lldb) c Process 3092991 resuming Process 3092991 stopped * thread #1, name = 'a.out', stop reason = breakpoint 3.1 frame #0: 0x000000000040052a a.out`main at main.cpp:6:14 (lldb) processor-trace show-instr-log thread #1: tid=3092991 0x40050f <+15>: movl $0x0, -0x8(%rbp) 0x400516 <+22>: movl $0x0, -0xc(%rbp) 0x40051d <+29>: cmpl $0x2710, -0xc(%rbp) ; imm = 0x2710 0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp 0x400524 <+36>: jge 0x400546 ; <+70> at main.cpp >>> The trace was re-enabled correctly and includes the instruction of the first reading. ``` Those instructions correspond to these lines ``` 3 int main() { 4 int z = 0; 5 for (int i = 0; i < 10000; i++) { 6 z += fun(z) ... ``` Differential Revision: https://reviews.llvm.org/D85241 |
||
---|---|---|
.. | ||
bindings | ||
cmake | ||
docs | ||
examples | ||
include/lldb | ||
packages/Python | ||
resources | ||
scripts | ||
source | ||
test | ||
third_party/Python/module | ||
tools | ||
unittests | ||
utils | ||
.clang-format | ||
.clang-tidy | ||
.gitignore | ||
CMakeLists.txt | ||
CODE_OWNERS.txt | ||
LICENSE.TXT | ||
use_lldb_suite_root.py |