| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Fix offset computation in RegisterContextUnwind (#137155) AddressFunctionScope was always returning the first address range of the function (assuming it was the only one). This doesn't work for RegisterContextUnwind (it's only caller), when the function doesn't start at the lowest address because it throws off the 'how many bytes "into" a function I am' computation. This patch replaces the result with a call to (recently introduced) SymbolContext::GetFunctionOrSymbolAddress. | 1 年前 | |
[lldb] Make AddressRange dump easier on the eye (#141062) | 1 年前 | |
[lldb] Expose discontinuous functions through SBFunction::GetRanges (#117532) SBFunction::GetEndAddress doesn't really make sense for discontinuous functions, so I'm declaring it deprecated. GetStartAddress sort of makes sense, if one uses it to find the functions entry point, so I'm keeping that undeprecated. I've made the test a Shell tests because these make it easier to create discontinuous functions regardless of the host os and architecture. They do make testing the python API harder, but I think I've managed to come up with something not entirely unreasonable. | 1 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
Re-land "[lldb] Expose a const iterator for SymbolContextList" Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications to fix tests. I originally reverted this because it caused a test to fail on Linux. The problem was that I inverted a condition on accident. | 3 年前 | |
[lldb] Add Model Context Protocol (MCP) support to LLDB (#143628) This PR adds an MCP (Model Context Protocol ) server to LLDB. For motivation and background, please refer to the corresponding RFC: https://discourse.llvm.org/t/rfc-adding-mcp-support-to-lldb/86798 I implemented this as a new kind of plugin. The idea is that we could support multiple protocol servers (e.g. if we want to support DAP from within LLDB). This also introduces a corresponding top-level command ( protocol-server) with two subcommands to start and stop the server. (lldb) protocol-server start MCP tcp://localhost:1234 MCP server started with connection listeners: connection://[::1]:1234, connection://[127.0.0.1]:1234 The MCP sever supports one tool (lldb_command) which executes a command, but can easily be extended with more commands. | 1 年前 | |
[lldb] Turn lldb_private::Status into a value type. (#106163) This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ResultTy DoFoo(Status& error) to llvm::Expected<ResultTy> DoFoo() How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) plus the occasional manual cleanup. | 1 年前 | |
[lldb] Support OSC escape codes for native progress (#162162) This PR adds support for emitting the OSC 9;4 sequences to show a GUI native progress bar. There's a limited number of terminal emulators that support this, so for now this requires explicit opt-in through a setting. I'm reusing the existing show-progress setting, which became a NOOP with the introduction of the statusline. The option now defaults to off. Implements #160369 | 9 个月前 | |
Modify the localCache API to require an explicit commit on CachedFile… (#136121) …Stream. CachedFileStream has previously performed the commit step in its destructor, but this means its only recourse for error handling is report_fatal_error. Modify this to add an explicit commit() method, and call this in the appropriate places with appropriate error handling for the location. Currently the destructor of CacheStream gives an assert failure in Debug builds if commit() was not called. This will help track down any remaining uses of the API that assume the old destructior behaviour. In Release builds we fall back to the previous behaviour and call report_fatal_error if the commit fails. This is version 2 of this PR, superseding reverted PR https://github.com/llvm/llvm-project/pull/115331 . I have incorporated a change to the testcase to make it more reliable on Windows, as well as two follow-up changes (https://github.com/llvm/llvm-project/commit/df79000896101acc9b8d7435e59f767b36c00ac8 and https://github.com/llvm/llvm-project/commit/b0baa1d8bd68a2ce2f7c5f2b62333e410e9122a1) that were also reverted when 115331 was reverted. --------- Co-authored-by: Augie Fackler <augie@google.com> Co-authored-by: Vitaly Buka <vitalybuka@google.com> | 1 年前 | |
[lldb] Ensure FILE* access mode is correctly specified when creating a NativeFile. (#167764) If we open a NativeFile with a FILE*, the OpenOptions default to eOpenOptionReadOnly. This is an issue in python scripts if you try to write to one of the files like print("Hi", file=lldb.debugger.GetOutputFileHandle()). To address this, we need to specify the access mode whenever we create a NativeFile from a FILE*. I also added an assert on the NativeFile that validates the file is opened with the correct access mode and updated NativeFile::Read and NativeFile::Write to check the access mode. Before these changes: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") Traceback (most recent call last): File "<input>", line 1, in <module> io.UnsupportedOperation: not writable After: $ lldb -b -O 'script lldb.debugger.GetOutputFileHandle().write("abc")' (lldb) script lldb.debugger.GetOutputFileHandle().write("abc") abc3 Fixes #122387 | 8 个月前 | |
[lldb] Create a single Severity enum in lldb-enumerations (#90917) We have 3 different enums all expressing severity (info, warning, error). Remove all uses with a new Severity enum in lldb-enumerations.h. | 2 年前 | |
Fix call site breakpoint patch (#114158) This fixes the two test suite failures that I missed in the PR: https://github.com/llvm/llvm-project/pull/112939 One was a poorly written test case - it assumed that on connect to a gdb-remote with a running process, lldb MUST have fetched all the frame 0 registers. In fact, there's no need for it to do so (as the CallSite patch showed...) and if we don't need to we shouldn't. So I fixed the test to only expect a g packet AFTER calling read_registers. The other was a place where some code had used 0 when it meant LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where it was still compared to 0. | 1 年前 | |
[libcxxabi][ItaniumDemangle] Separate GtIsGt counter into more states (#166578) Currently OutputBuffer::GtIsGt is used to tell us if we're inside template arguments and have printed a '(' without a closing ')'. If so, we don't need to quote '<' when printing it as part of a binary expression inside a template argument. Otherwise we need to. E.g., foo<a<(b < c)>> // Quotes around binary expression needed. LLDB's TrackingOutputBuffer has heuristics that rely on checking whether we are inside template arguments, regardless of the current parentheses depth. We've been using isGtInsideTemplateArgs for this, but that isn't correct. Resulting in us incorrectly tracking the basename of function like: void func<(foo::Enum)1>() Here GtIsGt > 0 despite us being inside template arguments (because we incremented it when seeing '('). This patch adds a isInsideTemplateArgs API which LLDB will use to more accurately track parts of the demangled name. To make sure this API doesn't go untested in the actual libcxxabi test-suite, I changed the existing GtIsGt logic to use it. Also renamed the various variables/APIs involved to make it (in my opinion) more straightforward to understand what's going on. But happy to rename it back if people disagree. Also adjusted LLDB to use the newly introduced API (and added a unit-test that would previously fail). | 9 个月前 | |
[lldb] [disassembler] chore: update VariableAnnotator::Annotate to except only Instruction as param and drop module and target (#168276) | 8 个月前 | |
[lldb] Added a warning in case of instruction decode failure (#164413) While testing baremetal lldb, I came across a situation that if an instruction could not be disassembled, lldb will print nothing as an output which might be a bit strange. I added at least printing warning in this case. | 9 个月前 | |
Reland "[lldb] Parse and display register field enums" (#97258)" (#97270) This reverts commit d9e659c538516036e40330b6a98160cbda4ff100. I could not reproduce the Mac OS ASAN failure locally but I narrowed it down to the test test_many_fields_same_enum. This test shares an enum between x0, which is 64 bit, and cpsr, which is 32 bit. My theory is that when it does register read x0, an enum type is created where the undlerying enumerators are 64 bit, matching the register size. Then it does register read cpsr which used the cached enum type, but this register is 32 bit. This caused lldb to try to read an 8 byte value out of a 4 byte allocation: READ of size 8 at 0x60200014b874 thread T0 <...> =>0x60200014b800: fa fa fd fa fa fa fd fa fa fa fd fa fa fa[04]fa To fix this I've added the register's size in bytes to the constructed enum type's name. This means that x0 uses: __lldb_register_fields_enum_some_enum_8 And cpsr uses: __lldb_register_fields_enum_some_enum_4 If any other registers use this enum and are read, they will use the cached type as long as their size matches, otherwise we make a new type. | 2 年前 | |
[lldb] Move ValueObject into its own library (NFC) (#113393) ValueObject is part of lldbCore for historical reasons, but conceptually it deserves to be its own library. This does introduce a (link-time) circular dependency between lldbCore and lldbValueObject, which is unfortunate but probably unavoidable because so many things in LLDB rely on ValueObject. We already have cycles and these libraries are never built as dylibs so while this doesn't improve the situation, it also doesn't make things worse. The header includes were updated with the following command: find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \; | 1 年前 | |
[lldb] fix parallel module loading deadlock for Linux DYLD (#166480) Another attempt at resolving the deadlock issue @GeorgeHuyubo discovered (his previous [attempt](https://github.com/llvm/llvm-project/pull/160225)). This change can be summarized as the following: * Plumb through a boolean flag to force no preload in GetOrCreateModules all the way through to LoadModuleAtAddress. * Parallelize Module::PreloadSymbols separately from Target::GetOrCreateModule and its caller LoadModuleAtAddress (this is what avoids the deadlock). These changes roughly maintain the performance characteristics of the previous implementation of parallel module loading. Testing on targets with between 5000 and 14000 modules, I saw similar numbers as before, often more than 10% faster in the new implementation across multiple trials for these massive targets. I think it's because we have less lock contention with this approach. # The deadlock See [bt.txt](https://github.com/user-attachments/files/22524471/bt.txt) for a sample backtrace of LLDB when the deadlock occurs. As @GeorgeHuyubo explains in his [PR](https://github.com/llvm/llvm-project/pull/160225), the deadlock occurs from an ABBA deadlock that happens when a thread context-switches out of Module::PreloadSymbols, goes into Target::GetOrCreateModule for another module, possibly entering this block: if (!module_sp) { // The platform is responsible for finding and caching an appropriate // module in the shared module cache. if (m_platform_sp) { error = m_platform_sp->GetSharedModule( module_spec, m_process_sp.get(), module_sp, &search_paths, &old_modules, &did_create_module); } else { error = Status::FromErrorString("no platform is currently set"); } } Module::PreloadSymbols holds a module-level mutex, and then GetSharedModule *attempts* to hold the mutex of the global shared ModuleList. So, this thread holds the module mutex, and waits on the global shared ModuleList mutex. A competing thread may execute Target::GetOrCreateModule, enter the same block as above, grabbing the global shared ModuleList mutex. Then, in ModuleList::GetSharedModule, we eventually call ModuleList::FindModules which eventually waits for the Module mutex held by the first thread (via Module::GetUUID). Thus, we deadlock. ## Reproducing the deadlock It might be worth noting that I've never been able to observe this deadlock issue during live debugging (e.g. launching or attaching to processes), however we were able to consistently reproduce this issue with coredumps when using the following settings: (lldb) settings set target.parallel-module-load true (lldb) settings set target.preload-symbols true (lldb) settings set symbols.load-on-demand false (lldb) target create --core /some/core/file/here # deadlock happens ## How this change avoids this deadlock This change avoids concurrent executions of Module::PreloadSymbols with Target::GetOrCreateModule by waiting until after the Target::GetOrCreateModule executions to run Module::PreloadSymbols in parallel. This avoids the ordering of holding a Module lock *then* the ModuleList lock, as Target::GetOrCreateModule executions maintain the ordering of the shared ModuleList lock first (from what I've read and tested). ## Why not read-write lock? Some feedback in https://github.com/llvm/llvm-project/pull/160225 was to modify mutexes used in these components with read-write locks. This might be a good idea overall, but I don't think it would *easily* resolve this specific deadlock. Module::PreloadSymbols would probably need a write lock to Module, so even if we had a read lock in Module::GetUUID we would still contend. Maybe the ModuleList lock could be a read lock that converts to a write lock if it chooses to update the module, but it seems likely that some thread would try to update the shared module list and then the write lock would contend again. Perhaps with deeper architectural changes, we could fix this issue? # Other attempts One downside of this approach (and the former approach of parallel module loading) is that each DYLD would need to implement this pattern themselves. With @clayborg's help, I looked at a few other approaches: * In Target::GetOrCreateModule, backgrounding the Module::PreloadSymbols call by adding it directly to the thread pool via Debugger::GetThreadPool().async(). This required adding a lock to Module::SetLoadAddress (probably should be one there already) since ObjectFileELF::SetLoadAddress is not thread-safe (updates sections). Unfortunately, during execution, this causes the preload symbols to run synchronously with Target::GetOrCreateModule, preventing us from truly parallelizing the execution. * In Module::PreloadSymbols, backgrounding the symtab and sym_file PreloadSymbols calls individually, but similar issues as the above. * Passing a callback function like https://github.com/swiftlang/llvm-project/pull/10746 instead of the boolean I use in this change. It's functionally the same change IMO, with some design tradeoffs: * Pro: the caller doesn't need to explicitly call Module::PreloadSymbols itself, and can instead call whatever function is passed into the callback. * Con: the caller needs to delay the execution of the callback such that it occurs after the GetOrCreateModule logic, otherwise we run into the same issue. I thought this would be trickier for the caller, requiring some kinda condition variable or otherwise storing the calls to execute afterwards. # Test Plan: ninja check-lldb --------- Co-authored-by: Tom Yang <toyang@fb.com> | 8 个月前 | |
[lldb][RISCV] fix LR/SC atomic sequence handling in lldb-server (#146072) lldb-server had limited support for single-stepping through the lr/sc atomic sequence. This patch enhances that support for all possible atomic sequences. The previous version contained an incorrect regex pattern in the test, causing the riscv-specific test to run on other platforms. This reland fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py) | 1 年前 | |
[lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC) There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec. | 3 年前 | |
[lldb] Introduce ScriptedFrame affordance (#149622) This patch introduces a new scripting affordance in lldb: ScriptedFrame. This allows user to produce mock stackframes in scripted threads and scripted processes from a python script. With this change, StackFrame can be synthetized from different sources: - Either from a dictionary containing a load address, and a frame index, which is the legacy way. - Or by creating a ScriptedFrame python object. One particularity of synthezising stackframes from the ScriptedFrame python object, is that these frame have an optional PC, meaning that they don't have a report a valid PC and they can act as shells that just contain static information, like the frame function name, the list of variables or registers, etc. It can also provide a symbol context. rdar://157260006 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 11 个月前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Ignore trailing spaces on quit confirmation (#162263) | 9 个月前 | |
[lldb] Use std::make_shared where possible (NFC) (#150714) This is a continuation of 68fd102, which did the same thing but only for StopInfo. Using make_shared is both safer and more efficient: - With make_shared, the object and the control block are allocated together, which is more efficient. - With make_shared, the enable_shared_from_this base class is properly linked to the control block before the constructor finishes, so shared_from_this() will be safe to use (though still not recommended during construction). | 1 年前 | |
[lldb][Lanugage][NFC] Adapt Language::ForEach to IterationAction (#161830) | 10 个月前 | |
[lldb][NFC] Remove plugin headers from Module (#167789) As of e4a672bc17a2a, lldbCore is free of plugins. These headers are no longer needed. | 8 个月前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 | |
[lldb] fix parallel module loading deadlock for Linux DYLD (#166480) Another attempt at resolving the deadlock issue @GeorgeHuyubo discovered (his previous [attempt](https://github.com/llvm/llvm-project/pull/160225)). This change can be summarized as the following: * Plumb through a boolean flag to force no preload in GetOrCreateModules all the way through to LoadModuleAtAddress. * Parallelize Module::PreloadSymbols separately from Target::GetOrCreateModule and its caller LoadModuleAtAddress (this is what avoids the deadlock). These changes roughly maintain the performance characteristics of the previous implementation of parallel module loading. Testing on targets with between 5000 and 14000 modules, I saw similar numbers as before, often more than 10% faster in the new implementation across multiple trials for these massive targets. I think it's because we have less lock contention with this approach. # The deadlock See [bt.txt](https://github.com/user-attachments/files/22524471/bt.txt) for a sample backtrace of LLDB when the deadlock occurs. As @GeorgeHuyubo explains in his [PR](https://github.com/llvm/llvm-project/pull/160225), the deadlock occurs from an ABBA deadlock that happens when a thread context-switches out of Module::PreloadSymbols, goes into Target::GetOrCreateModule for another module, possibly entering this block: if (!module_sp) { // The platform is responsible for finding and caching an appropriate // module in the shared module cache. if (m_platform_sp) { error = m_platform_sp->GetSharedModule( module_spec, m_process_sp.get(), module_sp, &search_paths, &old_modules, &did_create_module); } else { error = Status::FromErrorString("no platform is currently set"); } } Module::PreloadSymbols holds a module-level mutex, and then GetSharedModule *attempts* to hold the mutex of the global shared ModuleList. So, this thread holds the module mutex, and waits on the global shared ModuleList mutex. A competing thread may execute Target::GetOrCreateModule, enter the same block as above, grabbing the global shared ModuleList mutex. Then, in ModuleList::GetSharedModule, we eventually call ModuleList::FindModules which eventually waits for the Module mutex held by the first thread (via Module::GetUUID). Thus, we deadlock. ## Reproducing the deadlock It might be worth noting that I've never been able to observe this deadlock issue during live debugging (e.g. launching or attaching to processes), however we were able to consistently reproduce this issue with coredumps when using the following settings: (lldb) settings set target.parallel-module-load true (lldb) settings set target.preload-symbols true (lldb) settings set symbols.load-on-demand false (lldb) target create --core /some/core/file/here # deadlock happens ## How this change avoids this deadlock This change avoids concurrent executions of Module::PreloadSymbols with Target::GetOrCreateModule by waiting until after the Target::GetOrCreateModule executions to run Module::PreloadSymbols in parallel. This avoids the ordering of holding a Module lock *then* the ModuleList lock, as Target::GetOrCreateModule executions maintain the ordering of the shared ModuleList lock first (from what I've read and tested). ## Why not read-write lock? Some feedback in https://github.com/llvm/llvm-project/pull/160225 was to modify mutexes used in these components with read-write locks. This might be a good idea overall, but I don't think it would *easily* resolve this specific deadlock. Module::PreloadSymbols would probably need a write lock to Module, so even if we had a read lock in Module::GetUUID we would still contend. Maybe the ModuleList lock could be a read lock that converts to a write lock if it chooses to update the module, but it seems likely that some thread would try to update the shared module list and then the write lock would contend again. Perhaps with deeper architectural changes, we could fix this issue? # Other attempts One downside of this approach (and the former approach of parallel module loading) is that each DYLD would need to implement this pattern themselves. With @clayborg's help, I looked at a few other approaches: * In Target::GetOrCreateModule, backgrounding the Module::PreloadSymbols call by adding it directly to the thread pool via Debugger::GetThreadPool().async(). This required adding a lock to Module::SetLoadAddress (probably should be one there already) since ObjectFileELF::SetLoadAddress is not thread-safe (updates sections). Unfortunately, during execution, this causes the preload symbols to run synchronously with Target::GetOrCreateModule, preventing us from truly parallelizing the execution. * In Module::PreloadSymbols, backgrounding the symtab and sym_file PreloadSymbols calls individually, but similar issues as the above. * Passing a callback function like https://github.com/swiftlang/llvm-project/pull/10746 instead of the boolean I use in this change. It's functionally the same change IMO, with some design tradeoffs: * Pro: the caller doesn't need to explicitly call Module::PreloadSymbols itself, and can instead call whatever function is passed into the callback. * Con: the caller needs to delay the execution of the callback such that it occurs after the GetOrCreateModule logic, otherwise we run into the same issue. I thought this would be trickier for the caller, requiring some kinda condition variable or otherwise storing the calls to execute afterwards. # Test Plan: ninja check-lldb --------- Co-authored-by: Tom Yang <toyang@fb.com> | 8 个月前 | |
[lldb] Improve disassembly of unknown instructions (#145793) LLDB uses the LLVM disassembler to determine the size of instructions and to do the actual disassembly. Currently, if the LLVM disassembler can't disassemble an instruction, LLDB will ignore the instruction size, assume the instruction size is the minimum size for that device, print no useful opcode, and print nothing for the instruction. This patch changes this behavior to separate the instruction size and "can't disassemble". If the LLVM disassembler knows the size, but can't dissasemble the instruction, LLDB will use that size. It will print out the opcode, and will print "<unknown>" for the instruction. This is much more useful to both a user and a script. The impetus behind this change is to clean up RISC-V disassembly when the LLVM disassembler doesn't understand all of the instructions. RISC-V supports proprietary extensions, where the TD files don't know about certain instructions, and the disassembler can't disassemble them. Internal users want to be able to disassemble these instructions. With llvm-objdump, the solution is to pipe the output of the disassembly through a filter program. This patch modifies LLDB's disassembly to look more like llvm-objdump's, and includes an example python script that adds a command "fdis" that will disassemble, then pipe the output through a specified filter program. This has been tested with crustfilt, a sample filter located at https://github.com/quic/crustfilt . Changes in this PR: - Decouple "can't disassemble" with "instruction size". DisassemblerLLVMC::MCDisasmInstance::GetMCInst now returns a bool for valid disassembly, and has the size as an out paramter. Use the size even if the disassembly is invalid. Disassemble if disassemby is valid. - Always print out the opcode when -b is specified. Previously it wouldn't print out the opcode if it couldn't disassemble. - Print out RISC-V opcodes the way llvm-objdump does. Code for the new Opcode Type eType16_32Tuples by Jason Molenda. - Print <unknown> for instructions that can't be disassembled, matching llvm-objdump, instead of printing nothing. - Update max riscv32 and riscv64 instruction size to 8. - Add example "fdis" command script. - Added disassembly byte test for x86 with known and unknown instructions. - Added disassembly byte test for riscv32 with known and unknown instructions, with and without filtering. - Added test from Jason Molenda to RISC-V disassembly unit tests. | 1 年前 | |
[lldb/Target] Add SyntheticFrameProvider class (#166664) This patch introduces a new way to reconstruct the thread stackframe list. New SyntheticFrameProvider classes can lazy fetch a StackFrame at index using a provided StackFrameList. In can either be the real unwinder StackFrameList or we could also chain SyntheticFrameProviders to each others. This is the foundation work to implement ScriptedFrameProviders, which will come in a follow-up patch. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 9 个月前 | |
[lldb] Remove progress report coalescing (#130329) Remove support for coalescing progress reports in LLDB. This functionality was motivated by Xcode, which wanted to listen for less frequent, aggregated progress events at the cost of losing some detail. See the original RFC [1] for more details. Since then, they've reevaluated this trade-off and opted to listen for the regular, full fidelity progress events and do any post processing on their end. rdar://146425487 | 1 年前 | |
[lldb] Stop the protocol servers when terminating the plugin (#156101) Currently, the server keeps running until we call Stop from its dtor in the static destruction chain. This is too late: the server should stop when the plugin gets terminated. | 11 个月前 | |
| 1 年前 | ||
[lldb] Add Function::GetAddress and redirect some uses (#115836) Many calls to Function::GetAddressRange() were not interested in the range itself. Instead they wanted to find the address of the function (its entry point) or the base address for relocation of function-scoped entities (technically, the two don't need to be the same, but there's isn't good reason for them not to be). This PR creates a separate function for retrieving this, and changes the existing (non-controversial) uses to call that instead. | 1 年前 | |
[LLDB] Fix debuginfo ELF files overwriting Unified Section List (#166635) Recently I've been deep diving ELF cores in LLDB, aspiring to move LLDB closer to GDB in capability. One issue I encountered was a system lib losing it's unwind plan when loading the debuginfo. The reason for this was the debuginfo has the eh_frame section stripped and the main executable did not. The root cause of this was this line in [ObjectFileElf](https://github.com/llvm/llvm-project/blob/163933e9e7099f352ff8df1973f9a9c3d7def6c5/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1972) // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the // unified section list. if (GetType() != eTypeDebugInfo) unified_section_list = *m_sections_up; This would always be executed because CalculateType can never return an eTypeDebugInfo ObjectFile::Type ObjectFileELF::CalculateType() { switch (m_header.e_type) { case llvm::ELF::ET_NONE: // 0 - No file type return eTypeUnknown; case llvm::ELF::ET_REL: // 1 - Relocatable file return eTypeObjectFile; case llvm::ELF::ET_EXEC: // 2 - Executable file return eTypeExecutable; case llvm::ELF::ET_DYN: // 3 - Shared object file return eTypeSharedLibrary; case ET_CORE: // 4 - Core file return eTypeCoreFile; default: break; } return eTypeUnknown; } This makes sense as there isn't a explicit sh_type to denote that this file is a debuginfo. After some discussion with @clayborg and @GeorgeHuyubo we settled on joining the exciting unified section list with whatever new sections were being added. Adding each new unique section, or taking the section with the maximum file size. We picked this strategy to pick the section with the most information. In most scenarios, LHS should be SHT_NOBITS and RHS would be SHT_PROGBITS. Here is a diagram documenting the existing vs proposed new way. <img width="1666" height="1093" alt="image" src="https://github.com/user-attachments/assets/73ba9620-c737-439e-9934-ac350d88a3b5" /> | 9 个月前 | |
[lldb] Add missing StringExtras.h includes In preparation for removing the #include "llvm/ADT/StringExtras.h" from the header to source file of llvm/Support/Error.h, first add in all the missing includes that were previously included transitively through this header. This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1, and a11efd49266f. Differential Revision: https://reviews.llvm.org/D154775 | 3 年前 | |
[lldb] Eliminate SupportFileSP nullptr derefs (#168624) This patch fixes and eliminates the possibility of SupportFileSP ever being nullptr. The support file was originally treated like a value type, but became a polymorphic type and therefore has to be stored and passed around as a pointer. To avoid having all the callers check the validity of the pointer, I introduced the invariant that SupportFileSP is never null and always default constructed. However, without enforcement at the type level, that's fragile and indeed, we already identified two crashes where someone accidentally broke that invariant. This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that guarantees the pointer is never null. If default-constructed, it creates a default-constructed instance of the contained type. Note that I'm using private inheritance because you shouldn't inherit from standard library classes due to the lack of virtual destructor. So while the new abstraction looks like a std::shared_ptr, it is in fact **not** a shared pointer. Given that our destructor is trivial, we could use public inheritance, but currently there's no need for it. rdar://164989579 | 8 个月前 | |
[lldb] Rework how we pass the execution context to the statusline (#159887) Currently, we always pass the "selected" execution context to the statusline. When handling a process or thread event, we can be more precise, and build an execution context from the event data. This PR also adopts the new StoppedExecutionContext that was recently introduced. | 10 个月前 | |
[lldb] Gardening in StreamAsynchronousIO (NFC) (#127717) A handful of minor improvements to StreamAsynchronousIO: - Document the class. - Use a named enum value to distinguishing between stdout and stderr. - Add missing period to comment. - Clear the string instead of assigning to it. - Eliminate color argument. | 1 年前 | |
[LLDB][NFC] Refactor code extracting timestamp from StructuredData (#145954) Co-authored-by: Alex Langford <nirvashtzero@gmail.com> | 1 年前 | |
[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163) …ror() [NFC] | 1 年前 | |
[lldb] Devirtualize GetValueProperties (NFC) (#126583) Nobody is overriding GetValueProperties, so in practice we're always using m_collection_sp, which means we don't need to check the pointer. The temlated helpers were already operating on m_collection_sp directly so this makes the rest of the class consistent. | 1 年前 | |
[LLDB][Value] Require type size when reading a scalar (#153386) When reading a value as a scalar, the type size is required. It's returned as a std::optional. This optional isn't checked for scalar values, where it is unconditionally accessed. This came up in the [Shell/Process/Windows/msstl_smoke.cpp](https://github.com/llvm/llvm-project/blob/4e10b62442e9edf1769b98406b0559f515d9791f/lldb/test/Shell/Process/Windows/msstl_smoke.cpp) test. There, LLDB breaks at the function entry, so all locals aren't initialized yet. Most values will contain garbage. The [std::list synthetic provider](https://github.com/llvm/llvm-project/blob/4e10b62442e9edf1769b98406b0559f515d9791f/lldb/source/Plugins/Language/CPlusPlus/GenericList.cpp#L517) tries to read the value using GetData. However, in [ValueObject::GetData](https://github.com/llvm/llvm-project/blob/4e10b62442e9edf1769b98406b0559f515d9791f/lldb/source/ValueObject/ValueObject.cpp#L766), [ValueObjectChild::UpdateValue](https://github.com/llvm/llvm-project/blob/88c993fbc5b87030b082aeb99d4db94cc885ed1d/lldb/source/ValueObject/ValueObjectChild.cpp#L102) fails because the parent already failed to read its data, so m_value won't have a compiler type, thus the size can't be read. | 11 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 11 个月前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 8 个月前 | ||
| 5 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 |