main

文件	最后提交记录	最后更新时间
CMakeLists.txt	[trace][intelpt] Support system-wide tracing [3] - Refactor IntelPTThreadTrace I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can both single threads or single cores. In this diff I'm basically renaming the class, moving it to its own file, and removing all the pieces that are not used along with some basic cleanup. Differential Revision: https://reviews.llvm.org/D124648	4 年前
PerfTests.cpp	[trace][intelpt] Support system-wide tracing [14] - Decode per cpu This is the final functional patch to support intel pt decoding per cpu. It works by doing the following: - First, all context switches are split by tid and sorted in order. This produces a list of continuous executes per thread per core. - Then, all intel pt subtraces are split by PSB boundaries and assigned to individual thread continuous executions on the same core by doing simple TSC-based comparisons. - With this, we have, per thread, a sorted list of continuous executions each one with a list of intel pt subtraces. Up to this point, this is really fast because no instructions were actually decoded. - Then, each thread can be decoded by traversing their continuous executions and intel pt subtraces. An advantage of having these continuous executions is that we can identify if a continuous exexecution doesn't have intel pt data, and thus has a gap in it. We can later to more sofisticated comparisons to identify if within a continuous execution there are gaps. I'm adding a test as well. Differential Revision: https://reviews.llvm.org/D126394	4 年前
ProcfsTests.cpp	[lldb] Fix SIGSEGV in GetPtraceScope() in Procfs.cpp (#142224) # Symptom We have seen SIGSEGV like this: `` * thread #1, name = 'lldb-server', stop reason = SIGSEGV frame #0: 0x00007f39e529c993 libc.so.6__pthread_kill_internal(signo=11, threadid=<unavailable>) at pthread_kill.c:46:37 ... * frame #5: 0x000056027c94fe48 lldb-serverlldb_private::process_linux::GetPtraceScope() + 72 frame #6: 0x000056027c92f94f lldb-serverlldb_private::process_linux::NativeProcessLinux::Attach(int) + 1087 ... `` See [full stack trace](https://pastebin.com/X0d6QhYj). This happens on Linux where LLDB doesn't have access to /proc/sys/kernel/yama/ptrace_scope. A similar error (an unchecked Error) can be reproduced by running the newly added unit test without the fix. See the "Test" section below. # Root cause GetPtraceScope() ([code](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/lldb/source/Plugins/Process/Linux/Procfs.cpp#L77)) has the following if statement: llvm::Expected<int> lldb_private::process_linux::GetPtraceScope() { ErrorOr<std::unique_ptr<MemoryBuffer>> ptrace_scope_file = getProcFile("sys/kernel/yama/ptrace_scope"); if (!*ptrace_scope_file) return errorCodeToError(ptrace_scope_file.getError()); ... } The intention of the if statement is to check whether the ptrace_scope_file is an Error or not, and return the error if it is. However, the operator* of ErrorOr returns the value that is stored (which is a std::unique_ptr<MemoryBuffer>), so what the if condition actually do is to check if the unique pointer is non-null. Note that the method ErrorOr::getStorage() ([called by](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L162-L164) ErrorOr::operator *) **does** assert on whether or not HasError has been set (see [ErrorOr.h](https://github.com/llvm/llvm-project/blob/328f40f408c218f25695ea42c844e43bef38660b/llvm/include/llvm/Support/ErrorOr.h#L235-L243)). However, it seems this wasn't executed, probably because the LLDB was a release build. # Fix The fix is simply remove the * in the said if` statement.	1 年前