main

GGitHub[lldb] Parse qSupported MultiMemRead tag in GDB Remote Client (#163249)

ccf6e025创建于 2025年10月15日历史提交

文件	最后提交记录	最后更新时间
Linux	[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 年前
POSIX	Fix buildbot after https://reviews.llvm.org/D115073.	4 年前
Utility	[lldb][AArch64] Handle core file tag segments missing tag data (#145338) In the same way that memory regions may be known from a core file but not readable, tag segments can also have no content. For example: $ readelf --segments core <...> Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align <...> LOAD 0x0000000000002000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 RW 0x1000 <...> LOPROC+0x2 0x0000000000008000 0x0000ffff93899000 0x0000000000000000 0x0000000000000000 0x0000000000001000 0x0 This happens if you have a restricted coredump filter or size limit. The area of virtual memory this segment covers is 0x1000, or 4096 bytes aka one tagged page. It's FileSiz would normally be 0x80. Tags are packed 2 per byte and granules are 16 bytes. 4096 / 16 / 2 = 128 or 0x80. But here it has no data, and in theory a corrupt file might have some data but not all. This triggered an assert in UnpackTagsFromCoreFileSegment and crashed lldb. To fix this I have made UnpackTagsFromCoreFileSegment return an expected and returned an error in this case instead of asserting. This will be seen by the user, as shown in the added API test.	1 年前
elf-core	[lldb/cmake] Implicitly pass arguments to llvm_add_library (#142583) If we're not touching them, we don't need to do anything special to pass them along -- with one important caveat: due to how cmake arguments work, the implicitly passed arguments need to be specified before arguments that we handle. This isn't particularly nice, but the alternative is enumerating all arguments that can be used by llvm_add_library and the macros it calls (it also relies on implicit passing of some arguments to llvm_process_sources).	1 年前
gdb-remote	[lldb] Parse qSupported MultiMemRead tag in GDB Remote Client (#163249) This is in preparation for the new MultiMemRead packet discussed in the RFC [1]. An alternative to using qSupported would be having clients send an empty MultiMemRead packet. However, this is problematic because the already-existing packet M is a prefix of MultiMemRead; an empty reply would be ambiguous in this case. It is also risky that the stub might interpret the MultiMemRead as a valid M packet. Another advantage of qSupported is that this packet is already exchanged, so parsing a new field is simpler than having to exchange one extra packet. [1]: https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441	9 个月前
minidump	[LLDB] Process minidump better error messages (#149206) Prior, Process Minidump would return Status::FromErrorString("could not parse memory info"); For any unsuccessful memory read, with no differentiation between an error in LLDB and the data simply not being present. This lead to a lot of user confusion and overall pretty terrible user experience. To fix this I've refactored the APIs so we can pass an error back in an llvm expected. There were also no shell tests for memory read and process Minidump so I added one.	1 年前
CMakeLists.txt	[lldb] Fix intel trace plugin tests (#133826) The tests for the [intel-pt](https://github.com/llvm/llvm-project/blob/348374028970c956f2e49ab7553b495d7408ccd9/lldb/docs/use/intel_pt.rst) trace plugin were failing for multiple reasons. On machines where tracing is supported many of the tests were crashing because of a nullptr dereference. It looks like the core_file parameter in ProcessTrace::CreateInstance was once ignored, but was changed to always being dereferenced. This caused the tests to fail even when tracing was supported. On machines where tracing is not supported we would still run tests that attempt to take a trace. These would obviously fail because the required hardware is not present. Note that some of the tests simply read serialized json as trace files which does not require any special hardware. This PR fixes these two issues by guarding the pointer dereference and then skipping unsupported tests on machines. With these changes the trace tests pass on both types of machines. We also add a new unit test to validate that a process can be created with a nullptr core_file through the generic process trace plugin path.	1 年前
ProcessEventDataTest.cpp	[lldb] Remove vestigial remnants of reproducers (#135361) Not touching the SB API.	1 年前
ProcessTraceTest.cpp	[lldb] Fix intel trace plugin tests (#133826) The tests for the [intel-pt](https://github.com/llvm/llvm-project/blob/348374028970c956f2e49ab7553b495d7408ccd9/lldb/docs/use/intel_pt.rst) trace plugin were failing for multiple reasons. On machines where tracing is supported many of the tests were crashing because of a nullptr dereference. It looks like the core_file parameter in ProcessTrace::CreateInstance was once ignored, but was changed to always being dereferenced. This caused the tests to fail even when tracing was supported. On machines where tracing is not supported we would still run tests that attempt to take a trace. These would obviously fail because the required hardware is not present. Note that some of the tests simply read serialized json as trace files which does not require any special hardware. This PR fixes these two issues by guarding the pointer dereference and then skipping unsupported tests on machines. With these changes the trace tests pass on both types of machines. We also add a new unit test to validate that a process can be created with a nullptr core_file through the generic process trace plugin path.	1 年前