| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Add a gtest matcher for lldb_private::Value (#167427) This commit adds a new ValueMatcher class that can be used in gtest matching contexts to match against lldb_private::Value objects. We always match against the values value_type and context_type. For HostAddress values we will also match against the expected host buffer contents. For Scalar, FileAddress, and LoadAddress values we match against an expected Scalar value. The matcher is used to improve the quality of the tests in the DwarfExpressionTest.cpp file. Previously, the local Evaluate function would return an Expected<Scalar> value which makes it hard to verify that we actually get a Value of the expected type without adding custom evaluation code. Now we return an Expected<Value> so that we can match against the full value contents. The resulting change improves the quality of the existing checks and in some cases eliminates the need for special code to explicitly check value types. I followed the gtest [guide](https://google.github.io/googletest/gmock_cook_book.html#writing-new-monomorphic-matchers) for writing a new value matcher. | 9 个月前 | |
[lldb] Use StringRef::{starts,ends}_with (NFC) This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with. | 2 年前 | |
Revert " [clang] Refactor to remove clangDriver dependency from clangFrontend and flangFrontend (#165277)" (#169397) This reverts commit 3773bbe and relands the last revert attempt 40334b8. 3773bbe broke the build for the build configuration described in here: https://github.com/llvm/llvm-project/pull/165277#issuecomment-3572432250 | 9 个月前 | |
[llvm][lldb] Remove unused SmallVectorMemoryBuffer.h includes | 4 年前 | |
[lldb] Add mock dwarf delegate for testing dwarf expressions (#168468) This commit adds a MockDwarfDelegate class that can be used to control what dwarf version is used when evaluating an expression. We also add a simple test that shows how dwarf version can change the result of the expression. | 9 个月前 | |
[lldb] Inline expression evaluator error visualization (#106470) This patch is a reworking of Pete Lawrence's (@PortalPete) proposal for better expression evaluator error messages: https://github.com/llvm/llvm-project/pull/80938 Before: $ lldb -o "expr a+b" (lldb) expr a+b error: <user expression 0>:1:1: use of undeclared identifier 'a' a+b ^ error: <user expression 0>:1:3: use of undeclared identifier 'b' a+b ^ After: (lldb) expr a+b ^ ^ │ ╰─ error: use of undeclared identifier 'b' ╰─ error: use of undeclared identifier 'a' This eliminates the confusing <user expression 0>:1:3 source location and avoids echoing the expression to the console again, which results in a cleaner presentation that makes it easier to grasp what's going on. You can't see it here, bug the word "error" is now also in color, if so desired. Depends on https://github.com/llvm/llvm-project/pull/106442. | 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 | 11 个月前 | |
[lldb] Add a gtest matcher for lldb_private::Value (#167427) This commit adds a new ValueMatcher class that can be used in gtest matching contexts to match against lldb_private::Value objects. We always match against the values value_type and context_type. For HostAddress values we will also match against the expected host buffer contents. For Scalar, FileAddress, and LoadAddress values we match against an expected Scalar value. The matcher is used to improve the quality of the tests in the DwarfExpressionTest.cpp file. Previously, the local Evaluate function would return an Expected<Scalar> value which makes it hard to verify that we actually get a Value of the expected type without adding custom evaluation code. Now we return an Expected<Value> so that we can match against the full value contents. The resulting change improves the quality of the existing checks and in some cases eliminates the need for special code to explicitly check value types. I followed the gtest [guide](https://google.github.io/googletest/gmock_cook_book.html#writing-new-monomorphic-matchers) for writing a new value matcher. | 9 个月前 | |
[lldb] Add a gtest matcher for lldb_private::Value (#167427) This commit adds a new ValueMatcher class that can be used in gtest matching contexts to match against lldb_private::Value objects. We always match against the values value_type and context_type. For HostAddress values we will also match against the expected host buffer contents. For Scalar, FileAddress, and LoadAddress values we match against an expected Scalar value. The matcher is used to improve the quality of the tests in the DwarfExpressionTest.cpp file. Previously, the local Evaluate function would return an Expected<Scalar> value which makes it hard to verify that we actually get a Value of the expected type without adding custom evaluation code. Now we return an Expected<Value> so that we can match against the full value contents. The resulting change improves the quality of the existing checks and in some cases eliminates the need for special code to explicitly check value types. I followed the gtest [guide](https://google.github.io/googletest/gmock_cook_book.html#writing-new-monomorphic-matchers) for writing a new value matcher. | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 4 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 9 个月前 | ||
| 9 个月前 |