| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Enable locate module callback for all module loading (#160199) Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com> | 9 个月前 | |
| 1 年前 | ||
[lldb] Fix data race in statusline format handling (#142489) This fixes a data race between the main thread and the default event handler thread. The statusline format option value was protected by a mutex, but it was returned as a pointer, allowing one thread to access it while another was modifying it. Avoid the data race by returning format values by value instead of by pointer. | 1 年前 | |
[lldb] Remove vestigial remnants of reproducers (#135361) Not touching the SB API. | 1 年前 | |
[lldb] Add support for displaying __float128 variables (#98369) | 1 年前 | |
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] Mark scripted frames as synthetic instead of artificial (#153117) This patch changes the way frames created from scripted affordances like Scripted Threads are displayed. Currently, they're marked artificial which is used usually for compiler generated frames. This patch changes that behaviour by introducing a new synthetic StackFrame kind and moves 'artificial' to be a distinct StackFrame attribut. On top of making these frames less confusing, this allows us to know when a frame was created from a scripted affordance. rdar://155949703 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> | 11 个月前 | |
[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] Enable locate module callback for all module loading (#160199) Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com> | 9 个月前 | |
[lldb/Module] Allow for the creation of memory-only modules Summary: This patch extends the ModuleSpec class to include a DataBufferSP which contains the module data. If this data is provided, LLDB won't try to hit the filesystem to create the Module, but use only the data stored in the ModuleSpec. Reviewers: labath, espindola Subscribers: emaste, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83512 | 6 年前 | |
Add commands to list/enable/disable plugins (#134418) This commit adds three new commands for managing plugins. The list command will show which plugins are currently registered and their enabled state. The enable and disable commands can be used to enable or disable plugins. A disabled plugin will not show up to the PluginManager when it iterates over available plugins of a particular type. The purpose of these commands is to provide more visibility into registered plugins and allow users to disable plugins for experimental perf reasons. There are a few limitations to the current implementation 1. Only SystemRuntime and InstrumentationRuntime plugins are currently supported. We can easily extend the existing implementation to support more types. The scope was limited to these plugins to keep the PR size manageable. 2. Only "statically" know plugin types are supported (i.e. those managed by the PluginManager and not from plugin load). It is possibly we could support dynamic plugins as well, but I have not looked into it yet. | 1 年前 | |
[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 年前 | |
| 1 年前 | ||
[lldb] Unbreak test after 931d04be2fc8f3f0505b43e64297f75d526cb42a | 3 年前 | |
[lldb] Store SupportFiles in SourceManager::File (NFC) (#106639) To support detecting MD5 checksum mismatches, store a SupportFile rather than a plain FileSpec in SourceManager::File. | 1 年前 | |
[LLDB][Telemetry] Collect telemetry from client when allowed. (#129728) This patch is slightly different from other impl in that we dispatch client-telemetry via a different helper method. This is to make it easier for vendor to opt-out (simply by overriding the method to do nothing). There is also a configuration option to disallow collecting client telemetry. --------- Co-authored-by: Pavel Labath <pavel@labath.sk> | 1 年前 | |
[lldb/DWARF] Make manual dwarf index deterministic Currently, running the test suite with LLVM_ENABLE_EXPENSIVE_CHECKS=On causes a couple of tests to fail. This happens because they expect a certain order of variables (all of them happen to use the "target variable" command, but other lookup functions should suffer from the same issues), all of which have the same name. Sort algorithms often preserve the order of equivalent elements (in this case the entries in the NameToDIE map), but that not guaranteed, and LLVM_ENABLE_EXPENSIVE_CHECKS stresses that by pre-shuffling all inputs before sorting. While this could easily be fixed by relaxing the test expectations, having a deterministic output seems like a worthwhile goal, particularly, as this could have bigger consequences than just a different print order -- in some cases we just pick the first entry that we find, whatever that is. Therefore this patch makes the sort deterministic by introducing another sort key -- UniqueCString::Sort gets a value comparator functor, which can be used to sort elements with the same name -- in the DWARF case we use DIERef::operator<, which roughly equals the order in which the entries appear in the debug info, and matches the current "accidental" order. Using a extra functor seemed preferable to using stable_sort, as the latter allocates extra O(n) of temporary memory. I observed no difference in debug info parsing speed with this patch applied. Differential Revision: https://reviews.llvm.org/D118251 | 4 年前 | |
[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. | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 11 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 6 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 1 年前 |