| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Re-land [lldb][NFC] Mark ValueObject library with NO_PLUGIN_DEPENDENCIES (#167933) This is a fixed version of #167886. The build previously failed with BUILD_SHARED_LIBS=ON. After trying that locally, I uncovered a few other instances of lldb non-plugin libraries depending on clang transitively through lldbValueObject, so I added the correct clang libraries to their dependencies. | 8 个月前 | |
| 10 个月前 | ||
[lldb] Correct style of error messages (#156774) The LLVM Style Guide says the following about error and warning messages [1]: > [T]o match error message styles commonly produced by other tools, > start the first sentence with a lowercase letter, and finish the last > sentence without a period, if it would end in one otherwise. I often provide this feedback during code review, but we still have a bunch of places where we have inconsistent error message, which bothers me as a user. This PR identifies a handful of those places and updates the messages to be consistent. [1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages | 10 个月前 | |
[lldb] Remove unused local variables (NFC) (#138457) | 1 年前 | |
[lldb][Expression] Add structor variant to LLDB's function call labels (#149827) Depends on * https://github.com/llvm/llvm-project/pull/148877 * https://github.com/llvm/llvm-project/pull/155483 * https://github.com/llvm/llvm-project/pull/155485 * https://github.com/llvm/llvm-project/pull/154137 * https://github.com/llvm/llvm-project/pull/154142 This patch is an implementation of [this discussion](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) about handling ABI-tagged structors during expression evaluation. **Motivation** LLDB encodes the mangled name of a DW_TAG_subprogram into AsmLabels on function and method Clang AST nodes. This means that when calls to these functions get lowered into IR (when running JITted expressions), the address resolver can locate the appropriate symbol by mangled name (and it is guaranteed to find the symbol because we got the mangled name from debug-info, instead of letting Clang mangle it based on AST structure). However, we don't do this for CXXConstructorDecls/CXXDestructorDecls because these structor declarations in DWARF don't have a linkage name. This is because there can be multiple variants of a structor, each with a distinct mangling in the Itanium ABI. Each structor variant has its own definition DW_TAG_subprogram. So LLDB doesn't know which mangled name to put into the AsmLabel. Currently this means using ABI-tagged structors in LLDB expressions won't work (see [this RFC](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) for concrete examples). **Proposed Solution** The FunctionCallLabel encoding that we put into AsmLabels already supports stuffing more info about a DIE into it. So this patch extends the FunctionCallLabel to contain an optional discriminator (a sequence of bytes) which the SymbolFileDWARF plugin interprets as the constructor/destructor variant of that DIE. So when searching for the definition DIE, LLDB will include the structor variant in its heuristic for determining a match. There's a few subtleties here: 1. At the point at which LLDB first constructs the label, it has no way of knowing (just by looking at the debug-info declaration), which structor variant the expression evaluator is supposed to call. That's something that gets decided when compiling the expression. So we let the Clang mangler inject the correct structor variant into the AsmLabel during JITing. I adjusted the AsmLabelAttr mangling for this in https://github.com/llvm/llvm-project/pull/155485. An option would've been to create a new Clang attribute which behaved like an AsmLabel but with these special semantics for LLDB. My main concern there is that we'd have to adjust all the AsmLabelAttr checks around Clang to also now account for this new attribute. 2. The compiler is free to omit the C1 variant of a constructor if the C2 variant is sufficient. In that case it may alias C1 to C2, leaving us with only the C2 DW_TAG_subprogram in the object file. Linux is one of the platforms where this occurs. For those cases I added a heuristic in SymbolFileDWARF where we pick C2 if we asked for C1 but it doesn't exist. This may not always be correct (e.g., if the compiler decided to drop C1 for other reasons). 3. In https://github.com/llvm/llvm-project/pull/154142 Clang will emit C4/D4 variants of ctors/dtors on declarations. When resolving the FunctionCallLabel we will now substitute the actual variant that Clang told us we need to call into the mangled name. We do this using LLDB's ManglingSubstitutor. That way we find the definition DIE exactly the same way we do for regular function calls. 4. In cases where declarations and definitions live in separate modules, the DIE ID encoded in the function call label may not be enough to find the definition DIE in the encoded module ID. For those cases we fall back to how LLDB used to work: look up in all images of the target. To make sure we don't use the unified mangled name for the fallback lookup, we change the lookup name to whatever mangled name the FunctionCallLabel resolved to. rdar://104968288 | 10 个月前 | |
[lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (#106442) …NFC] This patch is the first patch in a series reworking of Pete Lawrence's (@PortalPete) amazing proposal for better expression evaluator error messages (https://github.com/llvm/llvm-project/pull/80938) This patch is preparatory patch for improving the rendering of expression evaluator diagnostics. Currently diagnostics are rendered into a string and the command interpreter layer then textually parses words like "error:" to (sometimes) color the output accordingly. In order to enable user interfaces to do better with diagnostics, we need to store them in a machine-readable fromat. This patch does this by adding a new llvm::Error kind wrapping a DiagnosticDetail struct that is used when the error type is eErrorTypeExpression. Multiple diagnostics are modeled using llvm::ErrorList. Right now the extra information is not used by the CommandInterpreter, this will be added in a follow-up patch! | 1 年前 | |
[LLDB] Add some declarations related to REPL support for mojo This simple diff declares some enum values needed to create a REPL for the mojo language. Differential Revision: https://reviews.llvm.org/D150303 | 3 年前 | |
[lldb] Upgrade CompilerType::GetBitSize to return llvm::Expected (#129601) This patch pushes the error handling boundary for the GetBitSize() methods from Runtime into the Type and CompilerType APIs. This makes it easier to diagnose problems thanks to more meaningful error messages being available. GetBitSize() is often the first thing LLDB asks about a type, so this method is particularly important for a better user experience. rdar://145667239 | 1 年前 | |
[lldb] Use llvm::find (NFC) (#143338) This patch should be mostly obvious, but in one place, this patch changes: const auto &it = std::find(...) to: auto it = llvm::find(...) We do not need to bind to a temporary with const ref. | 1 年前 | |
[lldb][IRExecutionUnit] Return error on failure to resolve function address (#161363) Starting with https://github.com/llvm/llvm-project/pull/148877 we started encoding the module ID of the function DIE we are currently parsing into its AsmLabel in the AST. When the JIT asks LLDB to resolve our special mangled name, we would locate the module and resolve the function/symbol we found in it. If we are debugging with a SymbolFileDWARFDebugMap, the module ID we encode is that of the .o file that is tracked by the debug-map. To resolve the address of the DIE in that .o file, we have to ask SymbolFileDWARFDebugMap::LinkOSOAddress to turn the address of the .o DIE into a real address in the linked executable. This will only work if the .o address was actually tracked by the debug-map. However, if the function definition appears in multiple .o files (which is the case for functions defined in headers), the linker will most likely de-deuplicate that definition. So most .o's definition DIEs for that function won't have a contribution in the debug-map, and thus we fail to resolve the address. When debugging Clang on Darwin, e.g., you'd see: (lldb) expr CXXDecl->getName() error: Couldn't look up symbols: $__lldb_func::0x1:0x4000d000002359da:_ZNK5clang9NamedDecl7getNameEv Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler. unless you were stopped in the .o file whose definition of getName made it into the final executable. The fix here is to error out if we fail to resolve the address, causing us to fall back on the old flow which did a lookup by mangled name, which the SymbolFileDWARFDebugMap will handle correctly. An alternative fix to this would be to encode the SymbolFileDWARFDebugMap's module-id. And implement SymbolFileDWARFDebugMap::ResolveFunctionCallLabel by doing a mangled name lookup. The proposed approach doesn't stop us from implementing that, so we could choose to do it in a follow-up. rdar://161393045 | 9 个月前 | |
[lldb][Expression] Encode Module and DIE UIDs into function AsmLabels (#148877) LLDB currently attaches AsmLabels to FunctionDecls such that that the IRExecutionUnit can determine which mangled name to call (we can't rely on Clang deriving the correct mangled name to call because the debug-info AST doesn't contain all the info that would be encoded in the DWARF linkage names). However, we don't attach AsmLabels for structors because they have multiple variants and thus it's not clear which mangled name to use. In the [RFC on fixing expression evaluation of abi-tagged structors](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) we discussed encoding the structor variant into the AsmLabels. Specifically in [this thread](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) we discussed that the contents of the AsmLabel are completely under LLDB's control and we could make use of it to uniquely identify a function by encoding the exact module and DIE that the function is associated with (mangled names need not be enough since two identical mangled symbols may live in different modules). So if we already have a custom AsmLabel format, we can encode the structor variant in a follow-up (the current idea is to append the structor variant as a suffix to our custom AsmLabel when Clang emits the mangled name into the JITted IR). Then we would just have to teach the IRExecutionUnit to pick the correct structor variant DIE during symbol resolution. The draft of this is available [here](https://github.com/llvm/llvm-project/pull/149827) This patch sets up the infrastructure for the custom AsmLabel format by encoding the module id, DIE id and mangled name in it. **Implementation** The flow is as follows: 1. Create the label in DWARFASTParserClang. The format is: $__lldb_func:module_id:die_id:mangled_name 2. When resolving external symbols in IRExecutionUnit, we parse this label and then do a lookup by DIE ID (or mangled name into the module if the encoded DIE is a declaration). Depends on https://github.com/llvm/llvm-project/pull/151355 | 11 个月前 | |
[lldb][nfc] Rename WritePointerToMemory argument's name (#157566) One of those arguments should be called pointer to correlate it to the name of the function and to distinguish it from the address where it will be written. | 10 个月前 | |
| 1 年前 | ||
[lldb] Convert registers values into target endian for expressions (#148836) Relates to https://github.com/llvm/llvm-project/issues/135707 Where it was reported that reading the PC using "register read" had different results to an expression "$pc". This was happening because registers are treated in lldb as pure "values" that don't really have an endian. We have to store them somewhere on the host of course, so the endian becomes host endian. When you want to use a register as a value in an expression you're pretending that it's a variable in memory. In target memory. Therefore we must convert the register value to that endian before use. The test I have added is based on the one used for XML register flags. Where I fake an AArch64 little endian and an s390x big endian target. I set up the data in such a way the pc value should print the same for both, either with register read or an expression. I considered just adding a live process test that checks the two are the same but with on one doing cross endian testing, I doubt it would have ever caught this bug. Simulating this means most of the time, little endian hosts will test little to little and little to big. In the minority of cases with a big endian host, they'll check the reverse. Covering all the combinations. | 11 个月前 | |
[lldb][NFC] Make the target's SectionLoadList private. (#113278) Lots of code around LLDB was directly accessing the target's section load list. This NFC patch makes the section load list private so the Target class can access it, but everyone else now uses accessor functions. This allows us to control the resolving of addresses and will allow for functionality in LLDB which can lazily resolve addresses in JIT plug-ins with a future patch. | 1 年前 | |
[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] Mark single-argument SourceLanguage constructors explicit (#166527) This avoids unintentional comparisons between SourceLanguage and LanguageType. Also marks operator bool explicit so we don't implicitly convert to bool. | 8 个月前 | |
[lldb] Store expression evaluator diagnostics in an llvm::Error (NFC) (#106442) …NFC] This patch is the first patch in a series reworking of Pete Lawrence's (@PortalPete) amazing proposal for better expression evaluator error messages (https://github.com/llvm/llvm-project/pull/80938) This patch is preparatory patch for improving the rendering of expression evaluator diagnostics. Currently diagnostics are rendered into a string and the command interpreter layer then textually parses words like "error:" to (sometimes) color the output accordingly. In order to enable user interfaces to do better with diagnostics, we need to store them in a machine-readable fromat. This patch does this by adding a new llvm::Error kind wrapping a DiagnosticDetail struct that is used when the error type is eErrorTypeExpression. Multiple diagnostics are modeled using llvm::ErrorList. Right now the extra information is not used by the CommandInterpreter, this will be added in a follow-up patch! | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 10 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 11 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 |