[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -511,22 +513,58 @@ ValueObjectSP
StackFrame::GetValueForVariableExpressionPath(
VariableSP &var_sp, Status &error) {
ExecutionContext exe_ctx;
CalculateExecutionContext(exe_ctx);
+
bool use_DIL = exe_ctx.GetTargetRef().GetUseDIL(&exe_ctx);
+
if (use_DIL)
return DILGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
var_sp, error);
-
- return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
options,
- var_sp, error);
+ else
+return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
+ options, var_sp, error);
}
ValueObjectSP StackFrame::DILGetValueForVariableExpressionPath(
llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
uint32_t options, lldb::VariableSP &var_sp, Status &error) {
- // This is a place-holder for the calls into the DIL parser and
- // evaluator. For now, just call the "real" frame variable implementation.
- return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
options,
- var_sp, error);
+ ValueObjectSP ret_val;
+ std::shared_ptr source =
+ std::make_shared(var_expr.data());
+
+ const bool check_ptr_vs_member =
+ (options & eExpressionPathOptionCheckPtrVsMember) != 0;
+ const bool no_fragile_ivar =
+ (options & eExpressionPathOptionsNoFragileObjcIvar) != 0;
+ const bool no_synth_child =
+ (options & eExpressionPathOptionsNoSyntheticChildren) != 0;
+
+ // Parse the expression.
+ Status parse_error, eval_error;
+ dil::DILParser parser(source, shared_from_this(), use_dynamic,
+!no_synth_child, !no_fragile_ivar,
check_ptr_vs_member);
+ dil::DILASTNodeUP tree = parser.Run(parse_error);
+ if (parse_error.Fail()) {
+error = std::move(parse_error);
+return ValueObjectSP();
+ }
labath wrote:
The benefits are definitely open to interpretation and we can skip this if you
feel strongly about it, but my reasoning is: the functionality which the
DILParser class implements is.. well.. a function -- you put the expression
string (plus some other data) in, and you get a parsed tree out. After the
caller doesn't, the caller doesn't need/want to refer back to the parser
object. Putting it into the function makes the whole parser object an
implementation detail, which is what I think it is in this case. The situation
would be different if we wanted to use the same parser object for parsing
multiple expressions. In that case, the two step process would be justified and
necessary.
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 95f7c2f - [lldb] Reduce duplication in two of DWARFDIE context functions (#122712)
Author: Pavel Labath
Date: 2025-01-14T09:26:02+01:00
New Revision: 95f7c2f88dc5b2fd851c3181b03300538151133e
URL:
https://github.com/llvm/llvm-project/commit/95f7c2f88dc5b2fd851c3181b03300538151133e
DIFF:
https://github.com/llvm/llvm-project/commit/95f7c2f88dc5b2fd851c3181b03300538151133e.diff
LOG: [lldb] Reduce duplication in two of DWARFDIE context functions (#122712)
This doesn't make much of a difference now, but it makes it easier to
add -gsimple-template-names support to these functions (the idea is to
add an argument to say whether you want the name as spelled in the debug
info, or the one embellished with template arguments -- we have use
cases for both).
Added:
Modified:
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
index 4b864b549f8ce6..6857878b354a05 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
@@ -376,6 +376,36 @@ lldb_private::Type *DWARFDIE::ResolveTypeUID(const
DWARFDIE &die) const {
return nullptr;
}
+static CompilerContext GetContextEntry(DWARFDIE die) {
+ auto ctx = [die](CompilerContextKind kind) {
+return CompilerContext(kind, ConstString(die.GetName()));
+ };
+
+ switch (die.Tag()) {
+ case DW_TAG_module:
+return ctx(CompilerContextKind::Module);
+ case DW_TAG_namespace:
+return ctx(CompilerContextKind::Namespace);
+ case DW_TAG_class_type:
+ case DW_TAG_structure_type:
+return ctx(CompilerContextKind::ClassOrStruct);
+ case DW_TAG_union_type:
+return ctx(CompilerContextKind::Union);
+ case DW_TAG_enumeration_type:
+return ctx(CompilerContextKind::Enum);
+ case DW_TAG_subprogram:
+return ctx(CompilerContextKind::Function);
+ case DW_TAG_variable:
+return ctx(CompilerContextKind::Variable);
+ case DW_TAG_typedef:
+return ctx(CompilerContextKind::Typedef);
+ case DW_TAG_base_type:
+return ctx(CompilerContextKind::Builtin);
+ default:
+llvm_unreachable("Check tag type in the caller!");
+ }
+}
+
static void GetDeclContextImpl(DWARFDIE die,
llvm::SmallSet &seen,
std::vector &context) {
@@ -388,34 +418,17 @@ static void GetDeclContextImpl(DWARFDIE die,
}
// Add this DIE's contribution at the end of the chain.
-auto push_ctx = [&](CompilerContextKind kind, llvm::StringRef name) {
- context.push_back({kind, ConstString(name)});
-};
switch (die.Tag()) {
case DW_TAG_module:
- push_ctx(CompilerContextKind::Module, die.GetName());
- break;
case DW_TAG_namespace:
- push_ctx(CompilerContextKind::Namespace, die.GetName());
- break;
case DW_TAG_class_type:
case DW_TAG_structure_type:
- push_ctx(CompilerContextKind::ClassOrStruct, die.GetName());
- break;
case DW_TAG_union_type:
- push_ctx(CompilerContextKind::Union, die.GetName());
- break;
case DW_TAG_enumeration_type:
- push_ctx(CompilerContextKind::Enum, die.GetName());
- break;
case DW_TAG_subprogram:
- push_ctx(CompilerContextKind::Function, die.GetName());
- break;
case DW_TAG_variable:
- push_ctx(CompilerContextKind::Variable, die.GetName());
- break;
case DW_TAG_typedef:
- push_ctx(CompilerContextKind::Typedef, die.GetName());
+ context.push_back(GetContextEntry(die));
break;
default:
break;
@@ -439,32 +452,18 @@ static void GetTypeLookupContextImpl(DWARFDIE die,
// Stop if we hit a cycle.
while (die && seen.insert(die.GetID()).second) {
// Add this DIE's contribution at the end of the chain.
-auto push_ctx = [&](CompilerContextKind kind, llvm::StringRef name) {
- context.push_back({kind, ConstString(name)});
-};
switch (die.Tag()) {
case DW_TAG_namespace:
- push_ctx(CompilerContextKind::Namespace, die.GetName());
- break;
case DW_TAG_class_type:
case DW_TAG_structure_type:
- push_ctx(CompilerContextKind::ClassOrStruct, die.GetName());
- break;
case DW_TAG_union_type:
- push_ctx(CompilerContextKind::Union, die.GetName());
- break;
case DW_TAG_enumeration_type:
- push_ctx(CompilerContextKind::Enum, die.GetName());
- break;
case DW_TAG_variable:
- push_ctx(CompilerContextKind::Variable, die.GetName());
- break;
case DW_TAG_typedef:
- push_ctx(CompilerContextKind::Typedef, die.GetName());
- break;
case DW_TAG_base_type:
- push_ctx(CompilerContextKind::Builtin, die.GetName());
+ context.push_back(GetContextEntry(die));
break;
+
// If any of the tags below appear in the parent chain, stop the decl
// context and return. Prior to these being in here, if a type existed in a
// namespace
[Lldb-commits] [lldb] [lldb] Reduce duplication in two of DWARFDIE context functions (PR #122712)
https://github.com/labath closed https://github.com/llvm/llvm-project/pull/122712 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] e87f94a - [llvm-project] Fix typos mutli and mutliple. NFC. (#122880)
Author: Jay Foad
Date: 2025-01-14T11:59:41Z
New Revision: e87f94a6a806a941242506680f88573d6a87a828
URL:
https://github.com/llvm/llvm-project/commit/e87f94a6a806a941242506680f88573d6a87a828
DIFF:
https://github.com/llvm/llvm-project/commit/e87f94a6a806a941242506680f88573d6a87a828.diff
LOG: [llvm-project] Fix typos mutli and mutliple. NFC. (#122880)
Added:
Modified:
clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
clang/lib/Basic/SourceManager.cpp
flang/test/HLFIR/associate-codegen.fir
libc/test/src/unistd/getopt_test.cpp
lldb/source/Commands/CommandObjectMemory.cpp
lldb/source/Target/StructuredDataPlugin.cpp
lldb/unittests/Target/RegisterFlagsTest.cpp
llvm/include/llvm/IR/DebugInfoMetadata.h
llvm/lib/Target/X86/X86LowerAMXType.cpp
llvm/test/CodeGen/AArch64/eon.ll
llvm/test/DebugInfo/X86/multiple-at-const-val.ll
llvm/test/Transforms/EarlyCSE/guards.ll
llvm/test/Transforms/InstCombine/matrix-multiplication-negation.ll
llvm/test/Transforms/LoopVectorize/RISCV/blend-any-of-reduction-cost.ll
mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-empty-tensor-elimination.mlir
mlir/test/Transforms/mem2reg.mlir
mlir/test/Transforms/sroa.mlir
Removed:
diff --git a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
index aec67808846b12..7a2d804e173ce4 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
@@ -342,7 +342,7 @@ static void ignoreTypeLocClasses(
Loc = Loc.getNextTypeLoc();
}
-static bool isMutliLevelPointerToTypeLocClasses(
+static bool isMultiLevelPointerToTypeLocClasses(
TypeLoc Loc,
std::initializer_list const &LocClasses) {
ignoreTypeLocClasses(Loc, {TypeLoc::Paren, TypeLoc::Qualified});
@@ -424,7 +424,7 @@ void UseAutoCheck::replaceExpr(
auto Diag = diag(Range.getBegin(), Message);
- bool ShouldReplenishVariableName = isMutliLevelPointerToTypeLocClasses(
+ bool ShouldReplenishVariableName = isMultiLevelPointerToTypeLocClasses(
TSI->getTypeLoc(), {TypeLoc::FunctionProto, TypeLoc::ConstantArray});
// Space after 'auto' to handle cases where the '*' in the pointer type is
diff --git a/clang/lib/Basic/SourceManager.cpp
b/clang/lib/Basic/SourceManager.cpp
index 44e982d3ee67fb..b1f2180c1d4627 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1222,7 +1222,7 @@ unsigned
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
return PLoc.getColumn();
}
-// Check if mutli-byte word x has bytes between m and n, included. This may
also
+// Check if multi-byte word x has bytes between m and n, included. This may
also
// catch bytes equal to n + 1.
// The returned value holds a 0x80 at each byte position that holds a match.
// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
diff --git a/flang/test/HLFIR/associate-codegen.fir
b/flang/test/HLFIR/associate-codegen.fir
index f5e015c4169f60..ad64959984a14a 100644
--- a/flang/test/HLFIR/associate-codegen.fir
+++ b/flang/test/HLFIR/associate-codegen.fir
@@ -372,7 +372,7 @@ func.func @_QPtest_multiple_expr_uses_inside_elemental() {
// CHECK: return
// CHECK: }
-// Verify that we properly recognize mutliple consequent hlfir.associate using
+// Verify that we properly recognize multiple consequent hlfir.associate using
// the same result of hlfir.elemental.
func.func @_QPtest_multitple_associates_for_same_expr() {
%c1 = arith.constant 1 : index
diff --git a/libc/test/src/unistd/getopt_test.cpp
b/libc/test/src/unistd/getopt_test.cpp
index e6e87720cde48d..8217f7bb6e7313 100644
--- a/libc/test/src/unistd/getopt_test.cpp
+++ b/libc/test/src/unistd/getopt_test.cpp
@@ -155,7 +155,7 @@ TEST_F(LlvmLibcGetoptTest, ParseArgInNext) {
EXPECT_EQ(test_globals::optind, 3);
}
-TEST_F(LlvmLibcGetoptTest, ParseMutliInOne) {
+TEST_F(LlvmLibcGetoptTest, ParseMultiInOne) {
array argv{"prog"_c, "-abc"_c, nullptr};
EXPECT_EQ(LIBC_NAMESPACE::getopt(2, argv.data(), "abc"), (int)'a');
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index b5612f21f11563..164c61d1720171 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1737,7 +1737,7 @@ class CommandObjectMemoryRegion : public
CommandObjectParsed {
// It is important that we track the address used to request the region as
// this will give the correct section name in the case that regions
overlap.
-// On Windows we get mutliple regions that start at the same place but are
+// On Windows we get multiple regions that start at the same place but are
//
diff erent sizes and refer to
diff erent sections.
std::
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
https://github.com/jayfoad closed https://github.com/llvm/llvm-project/pull/122880 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/122887 Close https://github.com/llvm/llvm-project/issues/90154 This patch is also an optimization to the lookup process to utilize the information provided by `export` keyword. Previously, in the lookup process, the `export` keyword only takes part in the check part, it doesn't get involved in the lookup process. That said, previously, in a name lookup for 'name', we would load all of declarations with the name 'name' and check if these declarations are valid or not. It works well. But it is inefficient since it may load declarations that may not be wanted. Note that this patch actually did a trick in the lookup process instead of bring module information to DeclarationName or considering module information when deciding if two declarations are the same. So it may not be a surprise to me if there are missing cases. But it is not a regression. It should be already the case. Issue reports are welcomed. In this patch, I tried to split the big lookup table into a lookup table as before and a module local lookup table, which takes a combination of the ID of the DeclContext and hash value of the primary module name as the key. And refactored `DeclContext::lookup()` method to take the module information. So that a lookup in a DeclContext won't load declarations that are local to **other** modules. And also I think it is already beneficial to split the big lookup table since it may reduce the conflicts during lookups in the hash table. BTW, this patch introduced a **regression** for a reachability rule in C++20 but it was false-negative. See 'clang/test/CXX/module/module.interface/p7.cpp' for details. This patch is not expected to introduce any other regressions for non-c++20-modules users since the module local lookup table should be empty for them. >From 01dae6621b6225e71f2a8c2e695f51fcf74e6b68 Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Thu, 26 Dec 2024 16:00:51 +0800 Subject: [PATCH] [C++20] [Modules] Support module level lookup Close https://github.com/llvm/llvm-project/issues/90154 This patch is also an optimization to the lookup process to utilize the information provided by `export` keyword. Previously, in the lookup process, the `export` keyword only takes part in the check part, it doesn't get involved in the lookup process. That said, previously, in a name lookup for 'name', we would load all of declarations with the name 'name' and check if these declarations are valid or not. It works well. But it is inefficient since it may load declarations that may not be wanted. Note that this patch actually did a trick in the lookup process instead of bring module information to DeclarationName or considering module information when deciding if two declarations are the same. So it may not be a surprise to me if there are missing cases. But it is not a regression. It should be already the case. Issue reports are welcomed. In this patch, I tried to split the big lookup table into a lookup table as before and a module local lookup table, which takes a combination of the ID of the DeclContext and hash value of the primary module name as the key. And refactored `DeclContext::lookup()` method to take the module information. So that a lookup in a DeclContext won't load declarations that are local to **other** modules. And also I think it is already beneficial to split the big lookup table since it may reduce the conflicts during lookups in the hash table. BTW, this patch introduced a **regression** for a reachability rule in C++20 but it was false-negative. See 'clang/test/CXX/module/module.interface/p7.cpp' for details. This patch is not expected to introduce any other regressions for non-c++20-modules users since the module local lookup table should be empty for them. --- clang/docs/ReleaseNotes.rst | 2 + clang/include/clang/AST/DeclBase.h| 10 + clang/include/clang/AST/ExternalASTMerger.h | 3 +- clang/include/clang/AST/ExternalASTSource.h | 10 +- .../clang/Sema/MultiplexExternalSemaSource.h | 3 +- .../include/clang/Serialization/ASTBitCodes.h | 6 + clang/include/clang/Serialization/ASTReader.h | 32 +- clang/include/clang/Serialization/ASTWriter.h | 16 +- clang/lib/AST/DeclBase.cpp| 23 +- clang/lib/AST/ExternalASTMerger.cpp | 3 +- clang/lib/AST/ExternalASTSource.cpp | 6 +- clang/lib/Interpreter/CodeCompletion.cpp | 6 +- .../lib/Sema/MultiplexExternalSemaSource.cpp | 7 +- clang/lib/Serialization/ASTReader.cpp | 195 ++--- clang/lib/Serialization/ASTReaderDecl.cpp | 69 +++-- clang/lib/Serialization/ASTReaderInternals.h | 72 - clang/lib/Serialization/ASTWriter.cpp | 273 ++ clang/lib/Serialization/ASTWriterDecl.cpp | 13 +- .../basic.scope/basic.scope.namespace/p2.cpp | 4 +- .../test/CXX/module/basic/basic.link/p2.cppm | 3 +
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
llvmbot wrote: @llvm/pr-subscribers-clang-modules Author: Chuanqi Xu (ChuanqiXu9) Changes Close https://github.com/llvm/llvm-project/issues/90154 This patch is also an optimization to the lookup process to utilize the information provided by `export` keyword. Previously, in the lookup process, the `export` keyword only takes part in the check part, it doesn't get involved in the lookup process. That said, previously, in a name lookup for 'name', we would load all of declarations with the name 'name' and check if these declarations are valid or not. It works well. But it is inefficient since it may load declarations that may not be wanted. Note that this patch actually did a trick in the lookup process instead of bring module information to DeclarationName or considering module information when deciding if two declarations are the same. So it may not be a surprise to me if there are missing cases. But it is not a regression. It should be already the case. Issue reports are welcomed. In this patch, I tried to split the big lookup table into a lookup table as before and a module local lookup table, which takes a combination of the ID of the DeclContext and hash value of the primary module name as the key. And refactored `DeclContext::lookup()` method to take the module information. So that a lookup in a DeclContext won't load declarations that are local to **other** modules. And also I think it is already beneficial to split the big lookup table since it may reduce the conflicts during lookups in the hash table. BTW, this patch introduced a **regression** for a reachability rule in C++20 but it was false-negative. See 'clang/test/CXX/module/module.interface/p7.cpp' for details. This patch is not expected to introduce any other regressions for non-c++20-modules users since the module local lookup table should be empty for them. --- Patch is 76.01 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/122887.diff 35 Files Affected: - (modified) clang/docs/ReleaseNotes.rst (+2) - (modified) clang/include/clang/AST/DeclBase.h (+10) - (modified) clang/include/clang/AST/ExternalASTMerger.h (+2-1) - (modified) clang/include/clang/AST/ExternalASTSource.h (+8-2) - (modified) clang/include/clang/Sema/MultiplexExternalSemaSource.h (+2-1) - (modified) clang/include/clang/Serialization/ASTBitCodes.h (+6) - (modified) clang/include/clang/Serialization/ASTReader.h (+28-4) - (modified) clang/include/clang/Serialization/ASTWriter.h (+13-3) - (modified) clang/lib/AST/DeclBase.cpp (+19-4) - (modified) clang/lib/AST/ExternalASTMerger.cpp (+2-1) - (modified) clang/lib/AST/ExternalASTSource.cpp (+3-3) - (modified) clang/lib/Interpreter/CodeCompletion.cpp (+4-2) - (modified) clang/lib/Sema/MultiplexExternalSemaSource.cpp (+4-3) - (modified) clang/lib/Serialization/ASTReader.cpp (+158-37) - (modified) clang/lib/Serialization/ASTReaderDecl.cpp (+52-17) - (modified) clang/lib/Serialization/ASTReaderInternals.h (+56-16) - (modified) clang/lib/Serialization/ASTWriter.cpp (+213-60) - (modified) clang/lib/Serialization/ASTWriterDecl.cpp (+11-2) - (modified) clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp (+2-2) - (modified) clang/test/CXX/module/basic/basic.link/p2.cppm (+1-2) - (modified) clang/test/CXX/module/module.import/p2.cpp (+2-8) - (modified) clang/test/CXX/module/module.interface/p7.cpp (+4-6) - (modified) clang/test/CXX/module/module.reach/p5.cpp (+1-2) - (modified) clang/test/Modules/Reachability-template-default-arg.cpp (+1-2) - (modified) clang/test/Modules/cxx20-10-1-ex2.cpp (+1-2) - (modified) clang/test/Modules/deduction-guide3.cppm (+1-3) - (added) clang/test/Modules/module-local-with-templates.cppm (+68) - (added) clang/test/Modules/pr90154.cppm (+25) - (modified) clang/unittests/AST/ExternalASTSourceTest.cpp (+2-1) - (modified) lldb/source/Plugins/ExpressionParser/Clang/ASTUtils.h (+6-4) - (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp (+2-1) - (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h (+5-3) - (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.cpp (+2-1) - (modified) lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.h (+2-1) - (modified) lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp (+2-1) ``diff diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst index 9eeb872aa57d79..142ed6e19b0a79 100644 --- a/clang/docs/ReleaseNotes.rst +++ b/clang/docs/ReleaseNotes.rst @@ -316,6 +316,8 @@ C++23 Feature Support C++20 Feature Support ^ +- Implemented module level lookup for C++20 modules. (#GH90154) + Resolutions to C++ Defect Reports ^ diff --git a/clang/include/clang/AST/DeclBase.h b/clang/include/clang/AST/DeclBase.h index 77abd8b657a616..b999ae6724e3cd 100644 -
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
@llvm/pr-subscribers-lldb
@llvm/pr-subscribers-clang
Author: Jay Foad (jayfoad)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/122880.diff
17 Files Affected:
- (modified) clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp (+2-2)
- (modified) clang/lib/Basic/SourceManager.cpp (+1-1)
- (modified) flang/test/HLFIR/associate-codegen.fir (+1-1)
- (modified) libc/test/src/unistd/getopt_test.cpp (+1-1)
- (modified) lldb/source/Commands/CommandObjectMemory.cpp (+1-1)
- (modified) lldb/source/Target/StructuredDataPlugin.cpp (+1-1)
- (modified) lldb/unittests/Target/RegisterFlagsTest.cpp (+1-1)
- (modified) llvm/include/llvm/IR/DebugInfoMetadata.h (+1-1)
- (modified) llvm/lib/Target/X86/X86LowerAMXType.cpp (+1-1)
- (modified) llvm/test/CodeGen/AArch64/eon.ll (+1-1)
- (modified) llvm/test/DebugInfo/X86/multiple-at-const-val.ll (+1-1)
- (modified) llvm/test/Transforms/EarlyCSE/guards.ll (+1-1)
- (modified) llvm/test/Transforms/InstCombine/matrix-multiplication-negation.ll
(+6-6)
- (modified)
llvm/test/Transforms/LoopVectorize/RISCV/blend-any-of-reduction-cost.ll (+2-2)
- (modified)
mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-empty-tensor-elimination.mlir
(+6-6)
- (modified) mlir/test/Transforms/mem2reg.mlir (+1-1)
- (modified) mlir/test/Transforms/sroa.mlir (+1-1)
``diff
diff --git a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
index aec67808846b12..7a2d804e173ce4 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
@@ -342,7 +342,7 @@ static void ignoreTypeLocClasses(
Loc = Loc.getNextTypeLoc();
}
-static bool isMutliLevelPointerToTypeLocClasses(
+static bool isMultiLevelPointerToTypeLocClasses(
TypeLoc Loc,
std::initializer_list const &LocClasses) {
ignoreTypeLocClasses(Loc, {TypeLoc::Paren, TypeLoc::Qualified});
@@ -424,7 +424,7 @@ void UseAutoCheck::replaceExpr(
auto Diag = diag(Range.getBegin(), Message);
- bool ShouldReplenishVariableName = isMutliLevelPointerToTypeLocClasses(
+ bool ShouldReplenishVariableName = isMultiLevelPointerToTypeLocClasses(
TSI->getTypeLoc(), {TypeLoc::FunctionProto, TypeLoc::ConstantArray});
// Space after 'auto' to handle cases where the '*' in the pointer type is
diff --git a/clang/lib/Basic/SourceManager.cpp
b/clang/lib/Basic/SourceManager.cpp
index 44e982d3ee67fb..b1f2180c1d4627 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1222,7 +1222,7 @@ unsigned
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
return PLoc.getColumn();
}
-// Check if mutli-byte word x has bytes between m and n, included. This may
also
+// Check if multi-byte word x has bytes between m and n, included. This may
also
// catch bytes equal to n + 1.
// The returned value holds a 0x80 at each byte position that holds a match.
// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
diff --git a/flang/test/HLFIR/associate-codegen.fir
b/flang/test/HLFIR/associate-codegen.fir
index f5e015c4169f60..ad64959984a14a 100644
--- a/flang/test/HLFIR/associate-codegen.fir
+++ b/flang/test/HLFIR/associate-codegen.fir
@@ -372,7 +372,7 @@ func.func @_QPtest_multiple_expr_uses_inside_elemental() {
// CHECK: return
// CHECK: }
-// Verify that we properly recognize mutliple consequent hlfir.associate using
+// Verify that we properly recognize multiple consequent hlfir.associate using
// the same result of hlfir.elemental.
func.func @_QPtest_multitple_associates_for_same_expr() {
%c1 = arith.constant 1 : index
diff --git a/libc/test/src/unistd/getopt_test.cpp
b/libc/test/src/unistd/getopt_test.cpp
index e6e87720cde48d..8217f7bb6e7313 100644
--- a/libc/test/src/unistd/getopt_test.cpp
+++ b/libc/test/src/unistd/getopt_test.cpp
@@ -155,7 +155,7 @@ TEST_F(LlvmLibcGetoptTest, ParseArgInNext) {
EXPECT_EQ(test_globals::optind, 3);
}
-TEST_F(LlvmLibcGetoptTest, ParseMutliInOne) {
+TEST_F(LlvmLibcGetoptTest, ParseMultiInOne) {
array argv{"prog"_c, "-abc"_c, nullptr};
EXPECT_EQ(LIBC_NAMESPACE::getopt(2, argv.data(), "abc"), (int)'a');
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index b5612f21f11563..164c61d1720171 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1737,7 +1737,7 @@ class CommandObjectMemoryRegion : public
CommandObjectParsed {
// It is important that we track the address used to request the region as
// this will give the correct section name in the case that regions
overlap.
-// On Windows we get mutliple regions that start at the same place but are
+// On Windows we get multiple regions that start at the same place but are
// differ
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
llvmbot wrote:
@llvm/pr-subscribers-backend-x86
Author: Jay Foad (jayfoad)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/122880.diff
17 Files Affected:
- (modified) clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp (+2-2)
- (modified) clang/lib/Basic/SourceManager.cpp (+1-1)
- (modified) flang/test/HLFIR/associate-codegen.fir (+1-1)
- (modified) libc/test/src/unistd/getopt_test.cpp (+1-1)
- (modified) lldb/source/Commands/CommandObjectMemory.cpp (+1-1)
- (modified) lldb/source/Target/StructuredDataPlugin.cpp (+1-1)
- (modified) lldb/unittests/Target/RegisterFlagsTest.cpp (+1-1)
- (modified) llvm/include/llvm/IR/DebugInfoMetadata.h (+1-1)
- (modified) llvm/lib/Target/X86/X86LowerAMXType.cpp (+1-1)
- (modified) llvm/test/CodeGen/AArch64/eon.ll (+1-1)
- (modified) llvm/test/DebugInfo/X86/multiple-at-const-val.ll (+1-1)
- (modified) llvm/test/Transforms/EarlyCSE/guards.ll (+1-1)
- (modified) llvm/test/Transforms/InstCombine/matrix-multiplication-negation.ll
(+6-6)
- (modified)
llvm/test/Transforms/LoopVectorize/RISCV/blend-any-of-reduction-cost.ll (+2-2)
- (modified)
mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-empty-tensor-elimination.mlir
(+6-6)
- (modified) mlir/test/Transforms/mem2reg.mlir (+1-1)
- (modified) mlir/test/Transforms/sroa.mlir (+1-1)
``diff
diff --git a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
index aec67808846b12..7a2d804e173ce4 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
@@ -342,7 +342,7 @@ static void ignoreTypeLocClasses(
Loc = Loc.getNextTypeLoc();
}
-static bool isMutliLevelPointerToTypeLocClasses(
+static bool isMultiLevelPointerToTypeLocClasses(
TypeLoc Loc,
std::initializer_list const &LocClasses) {
ignoreTypeLocClasses(Loc, {TypeLoc::Paren, TypeLoc::Qualified});
@@ -424,7 +424,7 @@ void UseAutoCheck::replaceExpr(
auto Diag = diag(Range.getBegin(), Message);
- bool ShouldReplenishVariableName = isMutliLevelPointerToTypeLocClasses(
+ bool ShouldReplenishVariableName = isMultiLevelPointerToTypeLocClasses(
TSI->getTypeLoc(), {TypeLoc::FunctionProto, TypeLoc::ConstantArray});
// Space after 'auto' to handle cases where the '*' in the pointer type is
diff --git a/clang/lib/Basic/SourceManager.cpp
b/clang/lib/Basic/SourceManager.cpp
index 44e982d3ee67fb..b1f2180c1d4627 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1222,7 +1222,7 @@ unsigned
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
return PLoc.getColumn();
}
-// Check if mutli-byte word x has bytes between m and n, included. This may
also
+// Check if multi-byte word x has bytes between m and n, included. This may
also
// catch bytes equal to n + 1.
// The returned value holds a 0x80 at each byte position that holds a match.
// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
diff --git a/flang/test/HLFIR/associate-codegen.fir
b/flang/test/HLFIR/associate-codegen.fir
index f5e015c4169f60..ad64959984a14a 100644
--- a/flang/test/HLFIR/associate-codegen.fir
+++ b/flang/test/HLFIR/associate-codegen.fir
@@ -372,7 +372,7 @@ func.func @_QPtest_multiple_expr_uses_inside_elemental() {
// CHECK: return
// CHECK: }
-// Verify that we properly recognize mutliple consequent hlfir.associate using
+// Verify that we properly recognize multiple consequent hlfir.associate using
// the same result of hlfir.elemental.
func.func @_QPtest_multitple_associates_for_same_expr() {
%c1 = arith.constant 1 : index
diff --git a/libc/test/src/unistd/getopt_test.cpp
b/libc/test/src/unistd/getopt_test.cpp
index e6e87720cde48d..8217f7bb6e7313 100644
--- a/libc/test/src/unistd/getopt_test.cpp
+++ b/libc/test/src/unistd/getopt_test.cpp
@@ -155,7 +155,7 @@ TEST_F(LlvmLibcGetoptTest, ParseArgInNext) {
EXPECT_EQ(test_globals::optind, 3);
}
-TEST_F(LlvmLibcGetoptTest, ParseMutliInOne) {
+TEST_F(LlvmLibcGetoptTest, ParseMultiInOne) {
array argv{"prog"_c, "-abc"_c, nullptr};
EXPECT_EQ(LIBC_NAMESPACE::getopt(2, argv.data(), "abc"), (int)'a');
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index b5612f21f11563..164c61d1720171 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1737,7 +1737,7 @@ class CommandObjectMemoryRegion : public
CommandObjectParsed {
// It is important that we track the address used to request the region as
// this will give the correct section name in the case that regions
overlap.
-// On Windows we get mutliple regions that start at the same place but are
+// On Windows we get multiple regions that start at the same place but are
// different sizes and refer to different sections.
std:
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
llvmbot wrote:
@llvm/pr-subscribers-debuginfo
Author: Jay Foad (jayfoad)
Changes
---
Full diff: https://github.com/llvm/llvm-project/pull/122880.diff
17 Files Affected:
- (modified) clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp (+2-2)
- (modified) clang/lib/Basic/SourceManager.cpp (+1-1)
- (modified) flang/test/HLFIR/associate-codegen.fir (+1-1)
- (modified) libc/test/src/unistd/getopt_test.cpp (+1-1)
- (modified) lldb/source/Commands/CommandObjectMemory.cpp (+1-1)
- (modified) lldb/source/Target/StructuredDataPlugin.cpp (+1-1)
- (modified) lldb/unittests/Target/RegisterFlagsTest.cpp (+1-1)
- (modified) llvm/include/llvm/IR/DebugInfoMetadata.h (+1-1)
- (modified) llvm/lib/Target/X86/X86LowerAMXType.cpp (+1-1)
- (modified) llvm/test/CodeGen/AArch64/eon.ll (+1-1)
- (modified) llvm/test/DebugInfo/X86/multiple-at-const-val.ll (+1-1)
- (modified) llvm/test/Transforms/EarlyCSE/guards.ll (+1-1)
- (modified) llvm/test/Transforms/InstCombine/matrix-multiplication-negation.ll
(+6-6)
- (modified)
llvm/test/Transforms/LoopVectorize/RISCV/blend-any-of-reduction-cost.ll (+2-2)
- (modified)
mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-empty-tensor-elimination.mlir
(+6-6)
- (modified) mlir/test/Transforms/mem2reg.mlir (+1-1)
- (modified) mlir/test/Transforms/sroa.mlir (+1-1)
``diff
diff --git a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
index aec67808846b12..7a2d804e173ce4 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
@@ -342,7 +342,7 @@ static void ignoreTypeLocClasses(
Loc = Loc.getNextTypeLoc();
}
-static bool isMutliLevelPointerToTypeLocClasses(
+static bool isMultiLevelPointerToTypeLocClasses(
TypeLoc Loc,
std::initializer_list const &LocClasses) {
ignoreTypeLocClasses(Loc, {TypeLoc::Paren, TypeLoc::Qualified});
@@ -424,7 +424,7 @@ void UseAutoCheck::replaceExpr(
auto Diag = diag(Range.getBegin(), Message);
- bool ShouldReplenishVariableName = isMutliLevelPointerToTypeLocClasses(
+ bool ShouldReplenishVariableName = isMultiLevelPointerToTypeLocClasses(
TSI->getTypeLoc(), {TypeLoc::FunctionProto, TypeLoc::ConstantArray});
// Space after 'auto' to handle cases where the '*' in the pointer type is
diff --git a/clang/lib/Basic/SourceManager.cpp
b/clang/lib/Basic/SourceManager.cpp
index 44e982d3ee67fb..b1f2180c1d4627 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1222,7 +1222,7 @@ unsigned
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
return PLoc.getColumn();
}
-// Check if mutli-byte word x has bytes between m and n, included. This may
also
+// Check if multi-byte word x has bytes between m and n, included. This may
also
// catch bytes equal to n + 1.
// The returned value holds a 0x80 at each byte position that holds a match.
// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
diff --git a/flang/test/HLFIR/associate-codegen.fir
b/flang/test/HLFIR/associate-codegen.fir
index f5e015c4169f60..ad64959984a14a 100644
--- a/flang/test/HLFIR/associate-codegen.fir
+++ b/flang/test/HLFIR/associate-codegen.fir
@@ -372,7 +372,7 @@ func.func @_QPtest_multiple_expr_uses_inside_elemental() {
// CHECK: return
// CHECK: }
-// Verify that we properly recognize mutliple consequent hlfir.associate using
+// Verify that we properly recognize multiple consequent hlfir.associate using
// the same result of hlfir.elemental.
func.func @_QPtest_multitple_associates_for_same_expr() {
%c1 = arith.constant 1 : index
diff --git a/libc/test/src/unistd/getopt_test.cpp
b/libc/test/src/unistd/getopt_test.cpp
index e6e87720cde48d..8217f7bb6e7313 100644
--- a/libc/test/src/unistd/getopt_test.cpp
+++ b/libc/test/src/unistd/getopt_test.cpp
@@ -155,7 +155,7 @@ TEST_F(LlvmLibcGetoptTest, ParseArgInNext) {
EXPECT_EQ(test_globals::optind, 3);
}
-TEST_F(LlvmLibcGetoptTest, ParseMutliInOne) {
+TEST_F(LlvmLibcGetoptTest, ParseMultiInOne) {
array argv{"prog"_c, "-abc"_c, nullptr};
EXPECT_EQ(LIBC_NAMESPACE::getopt(2, argv.data(), "abc"), (int)'a');
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index b5612f21f11563..164c61d1720171 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1737,7 +1737,7 @@ class CommandObjectMemoryRegion : public
CommandObjectParsed {
// It is important that we track the address used to request the region as
// this will give the correct section name in the case that regions
overlap.
-// On Windows we get mutliple regions that start at the same place but are
+// On Windows we get multiple regions that start at the same place but are
// different sizes and refer to different sections.
std::v
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
https://github.com/jayfoad created
https://github.com/llvm/llvm-project/pull/122880
None
>From d9a92edae5d021eed39acbdb22fa195dff78315d Mon Sep 17 00:00:00 2001
From: Jay Foad
Date: Tue, 14 Jan 2025 10:00:41 +
Subject: [PATCH] [llvm-project] Fix typos mutli and mutliple. NFC.
---
.../clang-tidy/modernize/UseAutoCheck.cpp| 4 ++--
clang/lib/Basic/SourceManager.cpp| 2 +-
flang/test/HLFIR/associate-codegen.fir | 2 +-
libc/test/src/unistd/getopt_test.cpp | 2 +-
lldb/source/Commands/CommandObjectMemory.cpp | 2 +-
lldb/source/Target/StructuredDataPlugin.cpp | 2 +-
lldb/unittests/Target/RegisterFlagsTest.cpp | 2 +-
llvm/include/llvm/IR/DebugInfoMetadata.h | 2 +-
llvm/lib/Target/X86/X86LowerAMXType.cpp | 2 +-
llvm/test/CodeGen/AArch64/eon.ll | 2 +-
llvm/test/DebugInfo/X86/multiple-at-const-val.ll | 2 +-
llvm/test/Transforms/EarlyCSE/guards.ll | 2 +-
.../InstCombine/matrix-multiplication-negation.ll| 12 ++--
.../RISCV/blend-any-of-reduction-cost.ll | 4 ++--
.../one-shot-bufferize-empty-tensor-elimination.mlir | 12 ++--
mlir/test/Transforms/mem2reg.mlir| 2 +-
mlir/test/Transforms/sroa.mlir | 2 +-
17 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
index aec67808846b12..7a2d804e173ce4 100644
--- a/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/UseAutoCheck.cpp
@@ -342,7 +342,7 @@ static void ignoreTypeLocClasses(
Loc = Loc.getNextTypeLoc();
}
-static bool isMutliLevelPointerToTypeLocClasses(
+static bool isMultiLevelPointerToTypeLocClasses(
TypeLoc Loc,
std::initializer_list const &LocClasses) {
ignoreTypeLocClasses(Loc, {TypeLoc::Paren, TypeLoc::Qualified});
@@ -424,7 +424,7 @@ void UseAutoCheck::replaceExpr(
auto Diag = diag(Range.getBegin(), Message);
- bool ShouldReplenishVariableName = isMutliLevelPointerToTypeLocClasses(
+ bool ShouldReplenishVariableName = isMultiLevelPointerToTypeLocClasses(
TSI->getTypeLoc(), {TypeLoc::FunctionProto, TypeLoc::ConstantArray});
// Space after 'auto' to handle cases where the '*' in the pointer type is
diff --git a/clang/lib/Basic/SourceManager.cpp
b/clang/lib/Basic/SourceManager.cpp
index 44e982d3ee67fb..b1f2180c1d4627 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -1222,7 +1222,7 @@ unsigned
SourceManager::getPresumedColumnNumber(SourceLocation Loc,
return PLoc.getColumn();
}
-// Check if mutli-byte word x has bytes between m and n, included. This may
also
+// Check if multi-byte word x has bytes between m and n, included. This may
also
// catch bytes equal to n + 1.
// The returned value holds a 0x80 at each byte position that holds a match.
// see http://graphics.stanford.edu/~seander/bithacks.html#HasBetweenInWord
diff --git a/flang/test/HLFIR/associate-codegen.fir
b/flang/test/HLFIR/associate-codegen.fir
index f5e015c4169f60..ad64959984a14a 100644
--- a/flang/test/HLFIR/associate-codegen.fir
+++ b/flang/test/HLFIR/associate-codegen.fir
@@ -372,7 +372,7 @@ func.func @_QPtest_multiple_expr_uses_inside_elemental() {
// CHECK: return
// CHECK: }
-// Verify that we properly recognize mutliple consequent hlfir.associate using
+// Verify that we properly recognize multiple consequent hlfir.associate using
// the same result of hlfir.elemental.
func.func @_QPtest_multitple_associates_for_same_expr() {
%c1 = arith.constant 1 : index
diff --git a/libc/test/src/unistd/getopt_test.cpp
b/libc/test/src/unistd/getopt_test.cpp
index e6e87720cde48d..8217f7bb6e7313 100644
--- a/libc/test/src/unistd/getopt_test.cpp
+++ b/libc/test/src/unistd/getopt_test.cpp
@@ -155,7 +155,7 @@ TEST_F(LlvmLibcGetoptTest, ParseArgInNext) {
EXPECT_EQ(test_globals::optind, 3);
}
-TEST_F(LlvmLibcGetoptTest, ParseMutliInOne) {
+TEST_F(LlvmLibcGetoptTest, ParseMultiInOne) {
array argv{"prog"_c, "-abc"_c, nullptr};
EXPECT_EQ(LIBC_NAMESPACE::getopt(2, argv.data(), "abc"), (int)'a');
diff --git a/lldb/source/Commands/CommandObjectMemory.cpp
b/lldb/source/Commands/CommandObjectMemory.cpp
index b5612f21f11563..164c61d1720171 100644
--- a/lldb/source/Commands/CommandObjectMemory.cpp
+++ b/lldb/source/Commands/CommandObjectMemory.cpp
@@ -1737,7 +1737,7 @@ class CommandObjectMemoryRegion : public
CommandObjectParsed {
// It is important that we track the address used to request the region as
// this will give the correct section name in the case that regions
overlap.
-// On Windows we get mutliple regions that start at the same place but are
+// On Windows we get multiple regions that start at the same place but are
[Lldb-commits] [lldb] [lldb] Removed gdbserver ports map from lldb-server (PR #104238)
DavidSpickett wrote: Thanks! - https://github.com/llvm/llvm-project/commit/cfd7e024c6a97b0083f2e25a9d03d7dd516a0452#diff-9a29352a0c8c114f51b142b44cb1d5d6688787df1f78f3785ada73e1355a7379R463 https://github.com/llvm/llvm-project/pull/104238 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [flang] [libc] [lldb] [llvm] [mlir] [llvm-project] Fix typos mutli and mutliple. NFC. (PR #122880)
https://github.com/cor3ntin approved this pull request. https://github.com/llvm/llvm-project/pull/122880 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -2711,6 +2715,12 @@ class DeclContext {
bool Deserialize = false) const;
private:
+ /// Lookup all external visible declarations and the external declarations
+ /// within the same module specified by \param NamedModule. We can't
Michael137 wrote:
Should we replace `\param` here (and other places around the patch) with `\c`
(or `\ref`)? IIUC `\param` is just used to start a parameter description.
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/Michael137 commented: LLDB API adjustments look fine. Just left some minor comments re. documentation https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,17 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
+ /// \param NamedModule, when this is set the external module local
+ /// declarations within the same module of \param NamedModule will be found
+ /// too. The \param NamedModule may be different than the owning module of
+ /// \param DC since the same namespace can appear in multiple module units.
Michael137 wrote:
Since you're already here, could we add a `\param` description for each of the
three parameters. With a description of what each is used for? And turn the
references into `\c`
I find this sentence quite hard to follow:
> when this is set the external module local declarations within the same
> module of \param NamedModule will be found too
My understanding of modules is probably insufficient but what are "external
module local declarations within the same module"?
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 58708151ecaab8786c58b20eefc548dbdb23c8cc 0555df5f2bd726904e1ac21f44c9623aa057f831 --extensions cpp,cppm,h -- clang/test/Modules/module-local-with-templates.cppm clang/test/Modules/pr90154.cppm clang/include/clang/AST/DeclBase.h clang/include/clang/AST/ExternalASTMerger.h clang/include/clang/AST/ExternalASTSource.h clang/include/clang/Sema/MultiplexExternalSemaSource.h clang/include/clang/Serialization/ASTBitCodes.h clang/include/clang/Serialization/ASTReader.h clang/include/clang/Serialization/ASTWriter.h clang/lib/AST/DeclBase.cpp clang/lib/AST/ExternalASTMerger.cpp clang/lib/AST/ExternalASTSource.cpp clang/lib/Interpreter/CodeCompletion.cpp clang/lib/Sema/MultiplexExternalSemaSource.cpp clang/lib/Serialization/ASTReader.cpp clang/lib/Serialization/ASTReaderDecl.cpp clang/lib/Serialization/ASTReaderInternals.h clang/lib/Serialization/ASTWriter.cpp clang/lib/Serialization/ASTWriterDecl.cpp clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp clang/test/CXX/module/basic/basic.link/p2.cppm clang/test/CXX/module/module.import/p2.cpp clang/test/CXX/module/module.interface/p7.cpp clang/test/CXX/module/module.reach/p5.cpp clang/test/Modules/Reachability-template-default-arg.cpp clang/test/Modules/cxx20-10-1-ex2.cpp clang/test/Modules/deduction-guide3.cppm clang/unittests/AST/ExternalASTSourceTest.cpp lldb/source/Plugins/ExpressionParser/Clang/ASTUtils.h lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.cpp lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.h lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp `` View the diff from clang-format here. ``diff diff --git a/clang/include/clang/AST/ExternalASTSource.h b/clang/include/clang/AST/ExternalASTSource.h index 7dc448d875..a33e0cb853 100644 --- a/clang/include/clang/AST/ExternalASTSource.h +++ b/clang/include/clang/AST/ExternalASTSource.h @@ -150,8 +150,8 @@ public: /// \param Name the name of the declarations to find. /// \param NamedModule find declarations visible to the given module /// \c NamedModule . This may be different from owning module of \c DC since - /// there are declarations (e.g., namespace declaration) can appear in multiple - /// modules. + /// there are declarations (e.g., namespace declaration) can appear in + /// multiple modules. /// \return \c true if any declarations might have been found, \c false if /// we definitely have no declarations with tbis name. /// `` https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (PR #122783)
@@ -10,22 +10,46 @@
class DAPTestCaseBase(TestBase):
# set timeout based on whether ASAN was enabled or not. Increase
# timeout by a factor of 10 if ASAN is enabled.
-timeoutval = 10 * (10 if ('ASAN_OPTIONS' in os.environ) else 1)
+timeoutval = 10 * (10 if ("ASAN_OPTIONS" in os.environ) else 1)
+lldbLogChannels = ["default"]
NO_DEBUG_INFO_TESTCASE = True
def create_debug_adaptor(self, lldbDAPEnv=None):
"""Create the Visual Studio Code debug adaptor"""
self.assertTrue(
is_exe(self.lldbDAPExec), "lldb-dap must exist and be executable"
)
-log_file_path = self.getBuildArtifact("dap.txt")
+
+# DAP communication logs.
+dap_log = self.getBuildArtifact("dap.txt")
+# Enable lldb logs to aid in debugging failures.
+lldb_log = self.getBuildArtifact("lldb.log")
+
+init_commands = self.setUpCommands()
+init_commands.append(
+"log enable -Tpn -f {} lldb {}".format(
+lldb_log, " ".join(self.lldbLogChannels)
+)
+)
labath wrote:
I don't think we'd want to enable this everywhere. lldb-dap tests are already a
lot more verbose than other lldb tests (which use `self.TraceOn()` to guard
noisy parts of the code), and we already have machinery (the `--channel` dotest
flag) to enable logging (though it may not work with lldb-dap, and it's not
wired up to print them in a way that's visible in the buildbot UI).
https://github.com/llvm/llvm-project/pull/122783
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (PR #122783)
https://github.com/labath commented: Were you able to reproduce the windows failure (and confirm the problem was indeed in the pipe code), or is this an attempt at speculation? https://github.com/llvm/llvm-project/pull/122783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap] Ensure the IO forwarding threads are managed by the DAP object lifecycle. (PR #122783)
https://github.com/labath edited https://github.com/llvm/llvm-project/pull/122783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,17 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
+ /// \param NamedModule, when this is set the external module local
+ /// declarations within the same module of \param NamedModule will be found
+ /// too. The \param NamedModule may be different than the owning module of
+ /// \param DC since the same namespace can appear in multiple module units.
ChuanqiXu9 wrote:
I updated the description.
> My understanding of modules is probably insufficient but what are "external
> module local declarations within the same module"?
If you're still interested, I can explain this to you with a few examples:
```
// a.cppm
export module a;
int a() { return 43; } ; // a module-local declaration.
// a-impl.cc
module a:impl;
int use() { return a(); } // valid. Since we're in the same module `a` with
`a()`.
// use.cc
import a;
int get() { return a(); } // error: not in the same module with a()
```
The function `a()` in `a.cppm` has module linkage. And it is only visible to
module `a`. So I called it as a `module local declaration`. And for
`a-impl.cc`, from the perspective of compilation, the declaration `a()` is
external. So it is `external module local declaration`. Then for `use()` in
`a-impl.cc` and `a` in `a.cppm`, they are in the same module. So, for `use()`
in `a-impl.cc`, `a()` is "an external module local declaration within the same
module".
But given this may be confusing, I used the new description.
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -2711,6 +2715,12 @@ class DeclContext {
bool Deserialize = false) const;
private:
+ /// Lookup all external visible declarations and the external declarations
+ /// within the same module specified by \param NamedModule. We can't
ChuanqiXu9 wrote:
Done
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/122887
>From 3586c686980c3307856642c056caf572eb7ffe82 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 26 Dec 2024 16:00:51 +0800
Subject: [PATCH] [C++20] [Modules] Support module level lookup
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.
Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.
Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.
In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as the key.
And refactored `DeclContext::lookup()` method to take the module
information. So that a lookup in a DeclContext won't load declarations
that are local to **other** modules.
And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.
BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.
This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.
---
clang/docs/ReleaseNotes.rst | 2 +
clang/include/clang/AST/DeclBase.h| 10 +
clang/include/clang/AST/ExternalASTMerger.h | 3 +-
clang/include/clang/AST/ExternalASTSource.h | 15 +-
.../clang/Sema/MultiplexExternalSemaSource.h | 3 +-
.../include/clang/Serialization/ASTBitCodes.h | 6 +
clang/include/clang/Serialization/ASTReader.h | 32 +-
clang/include/clang/Serialization/ASTWriter.h | 16 +-
clang/lib/AST/DeclBase.cpp| 23 +-
clang/lib/AST/ExternalASTMerger.cpp | 3 +-
clang/lib/AST/ExternalASTSource.cpp | 6 +-
clang/lib/Interpreter/CodeCompletion.cpp | 6 +-
.../lib/Sema/MultiplexExternalSemaSource.cpp | 7 +-
clang/lib/Serialization/ASTReader.cpp | 195 ++---
clang/lib/Serialization/ASTReaderDecl.cpp | 69 +++--
clang/lib/Serialization/ASTReaderInternals.h | 72 -
clang/lib/Serialization/ASTWriter.cpp | 273 ++
clang/lib/Serialization/ASTWriterDecl.cpp | 13 +-
.../basic.scope/basic.scope.namespace/p2.cpp | 4 +-
.../test/CXX/module/basic/basic.link/p2.cppm | 3 +-
clang/test/CXX/module/module.import/p2.cpp| 10 +-
clang/test/CXX/module/module.interface/p7.cpp | 10 +-
clang/test/CXX/module/module.reach/p5.cpp | 3 +-
.../Reachability-template-default-arg.cpp | 3 +-
clang/test/Modules/cxx20-10-1-ex2.cpp | 3 +-
clang/test/Modules/deduction-guide3.cppm | 4 +-
.../Modules/module-local-with-templates.cppm | 79 +
clang/test/Modules/pr90154.cppm | 25 ++
clang/unittests/AST/ExternalASTSourceTest.cpp | 3 +-
.../Plugins/ExpressionParser/Clang/ASTUtils.h | 10 +-
.../ExpressionParser/Clang/ClangASTSource.cpp | 3 +-
.../ExpressionParser/Clang/ClangASTSource.h | 8 +-
.../Clang/ClangExternalASTSourceCallbacks.cpp | 3 +-
.../Clang/ClangExternalASTSourceCallbacks.h | 3 +-
.../AppleObjCRuntime/AppleObjCDeclVendor.cpp | 3 +-
35 files changed, 734 insertions(+), 197 deletions(-)
create mode 100644 clang/test/Modules/module-local-with-templates.cppm
create mode 100644 clang/test/Modules/pr90154.cppm
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9eeb872aa57d79..142ed6e19b0a79 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -316,6 +316,8 @@ C++23 Feature Support
C++20 Feature Support
^
+- Implemented module level lookup for C++20 modules. (#GH90154)
+
Resolutions to C++ Defect Reports
^
diff --git a/clang/include/clang/AST/DeclBase.h
b/clang/include/clang/AST/DeclBase.h
index 77abd8b657a616..8686c2fe95dd6d 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -836,6 +836,10 @@ class alignas(8) Decl {
return isFromASTFile() ? getImportedOwningModule() :
getLocalOwningModule();
}
+ /// G
[Lldb-commits] [lldb] [lldb][Linux] Mark memory regions used for shadow stacks (PR #117861)
https://github.com/omjavaid approved this pull request. https://github.com/llvm/llvm-project/pull/117861 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b1751fa - [lldb][Linux] Mark memory regions used for shadow stacks (#117861)
Author: David Spickett
Date: 2025-01-14T15:19:22Z
New Revision: b1751faada35e3456b2a3f6b6c9559b5d74d559b
URL:
https://github.com/llvm/llvm-project/commit/b1751faada35e3456b2a3f6b6c9559b5d74d559b
DIFF:
https://github.com/llvm/llvm-project/commit/b1751faada35e3456b2a3f6b6c9559b5d74d559b.diff
LOG: [lldb][Linux] Mark memory regions used for shadow stacks (#117861)
This is intended for use with Arm's Guarded Control Stack extension
(GCS). Which reuses some existing shadow stack support in Linux. It
should also work with the x86 equivalent.
A "ss" flag is added to the "VmFlags" line of shadow stack memory
regions in `/proc//smaps`. To keep the naming generic I've called
it shadow stack instead of guarded control stack.
Also the wording is "shadow stack: yes" because the shadow stack region
is just where it's stored. It's enabled for the whole process or it
isn't. As opposed to memory tagging which can be enabled per region, so
"memory tagging: enabled" fits better for that.
I've added a test case that is also intended to be the start of a set of
tests for GCS. This should help me avoid duplicating the inline assembly
needed.
Note that no special compiler support is needed for the test. However,
for the intial enabling of GCS (assuming the libc isn't doing it) we do
need to use an inline assembly version of prctl.
This is because as soon as you enable GCS, all returns are checked
against the GCS. If the GCS is empty, the program will fault. In other
words, you can never return from the function that enabled GCS, unless
you push values onto it (which is possible but not needed here).
So you cannot use the libc's prctl wrapper for this reason. You can use
that wrapper for anything else, as we do to check if GCS is enabled.
Added:
lldb/test/API/linux/aarch64/gcs/Makefile
lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
lldb/test/API/linux/aarch64/gcs/main.c
Modified:
lldb/include/lldb/Target/MemoryRegionInfo.h
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Commands/CommandObjectMemory.cpp
lldb/source/Plugins/Process/Utility/LinuxProcMaps.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
lldb/source/Target/MemoryRegionInfo.cpp
lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
lldb/unittests/Process/Utility/MemoryTagManagerAArch64MTETest.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
lldb/unittests/Process/minidump/MinidumpParserTest.cpp
Removed:
diff --git a/lldb/include/lldb/Target/MemoryRegionInfo.h
b/lldb/include/lldb/Target/MemoryRegionInfo.h
index 7e1385b210b8c6..dc37a7dbeda52a 100644
--- a/lldb/include/lldb/Target/MemoryRegionInfo.h
+++ b/lldb/include/lldb/Target/MemoryRegionInfo.h
@@ -29,11 +29,11 @@ class MemoryRegionInfo {
OptionalBool execute, OptionalBool shared,
OptionalBool mapped, ConstString name, OptionalBool flash,
lldb::offset_t blocksize, OptionalBool memory_tagged,
- OptionalBool stack_memory)
+ OptionalBool stack_memory, OptionalBool shadow_stack)
: m_range(range), m_read(read), m_write(write), m_execute(execute),
m_shared(shared), m_mapped(mapped), m_name(name), m_flash(flash),
m_blocksize(blocksize), m_memory_tagged(memory_tagged),
-m_is_stack_memory(stack_memory) {}
+m_is_stack_memory(stack_memory), m_is_shadow_stack(shadow_stack) {}
RangeType &GetRange() { return m_range; }
@@ -55,6 +55,8 @@ class MemoryRegionInfo {
OptionalBool GetMemoryTagged() const { return m_memory_tagged; }
+ OptionalBool IsShadowStack() const { return m_is_shadow_stack; }
+
void SetReadable(OptionalBool val) { m_read = val; }
void SetWritable(OptionalBool val) { m_write = val; }
@@ -77,6 +79,8 @@ class MemoryRegionInfo {
void SetMemoryTagged(OptionalBool val) { m_memory_tagged = val; }
+ void SetIsShadowStack(OptionalBool val) { m_is_shadow_stack = val; }
+
// Get permissions as a uint32_t that is a mask of one or more bits from the
// lldb::Permissions
uint32_t GetLLDBPermissions() const {
@@ -106,7 +110,8 @@ class MemoryRegionInfo {
m_blocksize == rhs.m_blocksize &&
m_memory_tagged == rhs.m_memory_tagged &&
m_pagesize == rhs.m_pagesize &&
- m_is_stack_memory == rhs.m_is_stack_memory;
+ m_is_stack_memory == rhs.m_is_stack_memory &&
+ m_is_shadow_stack == rhs.m_is_shadow_stack;
}
bool operator!=(const MemoryRegionInfo &rhs) const { return !(*this == rhs);
}
@@ -148,6 +153,7 @@ class MemoryRegionInfo {
lldb::offset_t m_blocksize = 0;
OptionalBool m_memory_tagged = eDontKnow;
OptionalBool m_is_stack_memory = eDontKnow;
+ OptionalBool m_is_shadow_stack =
[Lldb-commits] [lldb] [lldb][Linux] Mark memory regions used for shadow stacks (PR #117861)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/117861 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Linux] Add Control Protection Fault signal (PR #122917)
https://github.com/DavidSpickett created
https://github.com/llvm/llvm-project/pull/122917
This will be sent by Arm's Guarded Control Stack extension when an invalid
return is executed.
The signal does have an address we could show, but it's the PC at which the
fault occured. The debugger has plenty of ways to show you that already, so
I've left it out.
```
(lldb) c
Process 460 resuming
Process 460 stopped
* thread #1, name = 'test', stop reason = signal SIGSEGV: control protection
fault
frame #0: 0x00400784 test`main at main.c:57:1
54 afunc();
55 printf("return from main\n");
56 return 0;
-> 57 }
(lldb) dis
<...>
-> 0x400784 <+100>: ret
```
The new test case generates the signal by corrupting the link register then
attempting to return. This will work whether we manually enable GCS or the C
library does it for us.
(in the former case you could just return from main and it would fault)
>From d9ac0897a7ab03ab2b7655f4e344c8ed9f141daf Mon Sep 17 00:00:00 2001
From: David Spickett
Date: Fri, 16 Aug 2024 16:06:47 +0100
Subject: [PATCH] [lldb][Linux] Add Control Protection Fault signal
This will be sent by Arm's Guarded Control Stack extension
when an invalid return is executed.
The signal does have an address we could show, but it's the
PC at which the fault occured. The debugger has plenty of ways
to show you that already, so I've left it out.
```
(lldb) c
Process 460 resuming
Process 460 stopped
* thread #1, name = 'test', stop reason = signal SIGSEGV: control protection
fault
frame #0: 0x00400784 test`main at main.c:57:1
54 afunc();
55 printf("return from main\n");
56 return 0;
-> 57 }
(lldb) dis
<...>
-> 0x400784 <+100>: ret
```
The new test case generates the signal by corrupting the link
register then attempting to return. This will work whether we
manually enable GCS or the C library does it for us.
(in the former case you could just return from main and it would
fault)
---
.../Plugins/Process/Utility/LinuxSignals.cpp | 4
.../linux/aarch64/gcs/TestAArch64LinuxGCS.py | 22 +++
lldb/test/API/linux/aarch64/gcs/main.c| 17 +-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 3f25dbc6abbbe3..eaecc84df15d4c 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -20,6 +20,9 @@
#ifndef SEGV_MTESERR
#define SEGV_MTESERR 9
#endif
+#ifndef SEGV_CPERR
+#define SEGV_CPERR 10
+#endif
#define ADD_SIGCODE(signal_name, signal_value, code_name, code_value, ...)
\
static_assert(signal_name == signal_value,
\
@@ -82,6 +85,7 @@ void LinuxSignals::Reset() {
ADD_SIGCODE(SIGSEGV, 11, SEGV_BNDERR, 3, "failed address bounds checks",
SignalCodePrintOption::Bounds);
ADD_SIGCODE(SIGSEGV, 11, SEGV_MTEAERR, 8, "async tag check fault");
ADD_SIGCODE(SIGSEGV, 11, SEGV_MTESERR, 9, "sync tag check fault",
SignalCodePrintOption::Address);
+ ADD_SIGCODE(SIGSEGV, 11, SEGV_CPERR, 10, "control protection fault");
// Some platforms will occasionally send nonstandard spurious SI_KERNEL
// codes. One way to get this is via unaligned SIMD loads. Treat it as
invalid address.
ADD_SIGCODE(SIGSEGV, 11, SI_KERNEL, 0x80, "invalid address",
SignalCodePrintOption::Address);
diff --git a/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
b/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
index b425c9e548ee51..0928ff8e14e000 100644
--- a/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
+++ b/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
@@ -61,3 +61,25 @@ def test_gcs_region(self):
# Note that we must let the debugee get killed here as it cannot exit
# cleanly if GCS was manually enabled.
+
+@skipUnlessArch("aarch64")
+@skipUnlessPlatform(["linux"])
+def test_gcs_fault(self):
+if not self.isAArch64GCS():
+self.skipTest("Target must support GCS.")
+
+self.build()
+self.runCmd("file " + self.getBuildArtifact("a.out"),
CURRENT_EXECUTABLE_SET)
+self.runCmd("run", RUN_SUCCEEDED)
+
+if self.process().GetState() == lldb.eStateExited:
+self.fail("Test program failed to run.")
+
+self.expect(
+"thread list",
+"Expected stopped by SIGSEGV.",
+substrs=[
+"stopped",
+"stop reason = signal SIGSEGV: control protection fault",
+],
+)
diff --git a/lldb/test/API/linux/aarch64/gcs/main.c
b/lldb/test/API/linux/aarch64/gcs/main.c
index 9633ed2838f9e8..32a9b07c207436 100644
--- a/lldb/test/API/linux/aarch64/gcs/main.c
+++ b/lldb/test/API/linux/aarch64/gcs/main.c
@@ -36,6 +36,19 @@ unsigned long get_gcs_status() {
return mode;
}
+void gcs_signal() {
+
[Lldb-commits] [lldb] [lldb][Linux] Add Control Protection Fault signal (PR #122917)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: David Spickett (DavidSpickett)
Changes
This will be sent by Arm's Guarded Control Stack extension when an invalid
return is executed.
The signal does have an address we could show, but it's the PC at which the
fault occured. The debugger has plenty of ways to show you that already, so
I've left it out.
```
(lldb) c
Process 460 resuming
Process 460 stopped
* thread #1, name = 'test', stop reason = signal SIGSEGV: control
protection fault
frame #0: 0x00400784 test`main at main.c:57:1
54 afunc();
55 printf("return from main\n");
56 return 0;
-> 57}
(lldb) dis
<...>
-> 0x400784 <+100>: ret
```
The new test case generates the signal by corrupting the link register then
attempting to return. This will work whether we manually enable GCS or the C
library does it for us.
(in the former case you could just return from main and it would fault)
---
Full diff: https://github.com/llvm/llvm-project/pull/122917.diff
3 Files Affected:
- (modified) lldb/source/Plugins/Process/Utility/LinuxSignals.cpp (+4)
- (modified) lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py (+22)
- (modified) lldb/test/API/linux/aarch64/gcs/main.c (+16-1)
``diff
diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 3f25dbc6abbbe3..eaecc84df15d4c 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -20,6 +20,9 @@
#ifndef SEGV_MTESERR
#define SEGV_MTESERR 9
#endif
+#ifndef SEGV_CPERR
+#define SEGV_CPERR 10
+#endif
#define ADD_SIGCODE(signal_name, signal_value, code_name, code_value, ...)
\
static_assert(signal_name == signal_value,
\
@@ -82,6 +85,7 @@ void LinuxSignals::Reset() {
ADD_SIGCODE(SIGSEGV, 11, SEGV_BNDERR, 3, "failed address bounds checks",
SignalCodePrintOption::Bounds);
ADD_SIGCODE(SIGSEGV, 11, SEGV_MTEAERR, 8, "async tag check fault");
ADD_SIGCODE(SIGSEGV, 11, SEGV_MTESERR, 9, "sync tag check fault",
SignalCodePrintOption::Address);
+ ADD_SIGCODE(SIGSEGV, 11, SEGV_CPERR, 10, "control protection fault");
// Some platforms will occasionally send nonstandard spurious SI_KERNEL
// codes. One way to get this is via unaligned SIMD loads. Treat it as
invalid address.
ADD_SIGCODE(SIGSEGV, 11, SI_KERNEL, 0x80, "invalid address",
SignalCodePrintOption::Address);
diff --git a/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
b/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
index b425c9e548ee51..0928ff8e14e000 100644
--- a/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
+++ b/lldb/test/API/linux/aarch64/gcs/TestAArch64LinuxGCS.py
@@ -61,3 +61,25 @@ def test_gcs_region(self):
# Note that we must let the debugee get killed here as it cannot exit
# cleanly if GCS was manually enabled.
+
+@skipUnlessArch("aarch64")
+@skipUnlessPlatform(["linux"])
+def test_gcs_fault(self):
+if not self.isAArch64GCS():
+self.skipTest("Target must support GCS.")
+
+self.build()
+self.runCmd("file " + self.getBuildArtifact("a.out"),
CURRENT_EXECUTABLE_SET)
+self.runCmd("run", RUN_SUCCEEDED)
+
+if self.process().GetState() == lldb.eStateExited:
+self.fail("Test program failed to run.")
+
+self.expect(
+"thread list",
+"Expected stopped by SIGSEGV.",
+substrs=[
+"stopped",
+"stop reason = signal SIGSEGV: control protection fault",
+],
+)
diff --git a/lldb/test/API/linux/aarch64/gcs/main.c
b/lldb/test/API/linux/aarch64/gcs/main.c
index 9633ed2838f9e8..32a9b07c207436 100644
--- a/lldb/test/API/linux/aarch64/gcs/main.c
+++ b/lldb/test/API/linux/aarch64/gcs/main.c
@@ -36,6 +36,19 @@ unsigned long get_gcs_status() {
return mode;
}
+void gcs_signal() {
+ // If we enabled GCS manually, then we could just return from main to
generate
+ // a signal. However, if the C library enabled it, then we'd just exit
+ // normally. Assume the latter, and try to return to some bogus address to
+ // generate the signal.
+ __asm__ __volatile__(
+ // Corrupt the link register. This could be many numbers but 16 is a
+ // nicely aligned value that is unlikely to result in a fault because the
+ // PC is misaligned, which would hide the GCS fault.
+ "add x30, x30, #10\n"
+ "ret\n");
+}
+
int main() {
if (!(getauxval(AT_HWCAP2) & HWCAP2_GCS))
return 1;
@@ -50,5 +63,7 @@ int main() {
}
// By now we should have one memory region where the GCS is stored.
- return 0; // Set break point at this line.
+ gcs_signal(); // Set break point at this line.
+
+ return 0;
}
``
https://github.com/llvm/llvm-project/pull/122917
___
lldb-commits m
[Lldb-commits] [lldb] [lldb][Linux] Add Control Protection Fault signal (PR #122917)
@@ -50,5 +63,7 @@ int main() {
}
// By now we should have one memory region where the GCS is stored.
- return 0; // Set break point at this line.
+ gcs_signal(); // Set break point at this line.
DavidSpickett wrote:
The previously added `test_gcs_region` will stop here and then kill the process
instead of continuing. So it will work as it did before.
https://github.com/llvm/llvm-project/pull/122917
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
slydiman wrote: > LLDB, please ping us if you encounter problems after we merge this patch. https://lab.llvm.org/buildbot/#/builders/195/builds/3458 https://lab.llvm.org/buildbot/#/builders/197/builds/627 https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove unfiltered stop reason propagation from StopInfoMachException (PR #122817)
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/122817
>From b42dc01256c8a433629d3594d54e942417705f83 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Wed, 18 Dec 2024 14:47:08 -0800
Subject: [PATCH 1/3] [lldb] Remove unfiltered stop reason propagation from
StopInfoMachException
In the presence of OS plugins, StopInfoMachException currently
propagates breakpoint stop reasons even if those breakpoints were not
intended for a specific thread, effectively removing our ability to set
thread-specific breakpoints.
This was originally added in [1], but the motivation provided in the
comment does not seem strong enough to remove the ability to set
thread-specific breakpoints. The only way to break thread specific
breakpoints would be if a user set such a breakpoint and _then_ loaded
an OS plugin, a scenario which we would likely not want to support.
[1]:
https://github.com/swiftlang/llvm-project/commit/ab745c2ad865c07f3905482fd071ef36c024713a#diff-8ec6e41b1dffa7ac4b5841aae24d66442ef7ebc62c8618f89354d84594f91050R501
---
.../Process/Utility/StopInfoMachException.cpp | 9 ++---
.../plugins/python_os_plugin/TestPythonOSPlugin.py | 13 +
.../functionalities/plugins/python_os_plugin/main.c | 2 ++
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index d08e99f4844de3..698ba0f0f720f6 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -780,13 +780,8 @@ StopInfoSP
StopInfoMachException::CreateStopReasonWithMachException(
// but if it is for another thread, we can just report no reason. We
// don't need to worry about stepping over the breakpoint here, that
// will be taken care of when the thread resumes and notices that
-// there's a breakpoint under the pc. If we have an operating system
-// plug-in, we might have set a thread specific breakpoint using the
-// operating system thread ID, so we can't make any assumptions about
-// the thread ID so we must always report the breakpoint regardless
-// of the thread.
-if (bp_site_sp->ValidForThisThread(thread) ||
-thread.GetProcess()->GetOperatingSystem() != nullptr)
+// there's a breakpoint under the pc.
+if (bp_site_sp->ValidForThisThread(thread))
return StopInfo::CreateStopReasonWithBreakpointSiteID(
thread, bp_site_sp->GetID());
else if (is_trace_if_actual_breakpoint_missing)
diff --git
a/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
b/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
index 479c94c2315407..4b8471d1cc32be 100644
---
a/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
+++
b/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
@@ -219,3 +219,16 @@ def run_python_os_step(self):
6,
"Make sure we stepped from line 5 to line 6 in main.c",
)
+
+thread_bp_number = lldbutil.run_break_set_by_source_regexp(
+self, "Set tid-specific breakpoint here", num_expected_locations=1
+)
+breakpoint = target.FindBreakpointByID(thread_bp_number)
+# This breakpoint should not be hit.
+breakpoint.SetThreadID(123)
+process.Continue()
+
+frame = thread.GetFrameAtIndex(0)
+self.assertFalse(
+frame.IsValid(), "Should not stop, the breakpoint was not for this
thread."
+)
diff --git a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
index faa6dd58ecd62b..248ecc8f650d2a 100644
--- a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
+++ b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
@@ -3,5 +3,7 @@
int main (int argc, char const *argv[], char const *envp[])
{
puts("stop here"); // Set breakpoint here
+puts("hello");
+puts("don't stop here on tid-specific breakpoint"); // Set tid-specific
breakpoint here
return 0;
}
>From 2050c68df4edc32bb24d6bb0123f0ab99c6dcd94 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Mon, 13 Jan 2025 16:06:21 -0800
Subject: [PATCH 2/3] fixup! change regex string in test
---
lldb/test/API/functionalities/plugins/python_os_plugin/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
index 248ecc8f650d2a..deb80027c5e6c2 100644
--- a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
+++ b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
@@ -4,6 +4,6 @@ int ma
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,17 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
+ /// \param NamedModule, when this is set the external module local
+ /// declarations within the same module of \param NamedModule will be found
+ /// too. The \param NamedModule may be different than the owning module of
+ /// \param DC since the same namespace can appear in multiple module units.
Michael137 wrote:
Great thanks! That all makes sense to me now
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,18 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
- /// \return \c true if any declarations might have been found, \c false if
- /// we definitely have no declarations with tbis name.
+ /// \param DC since the same namespace can appear in multiple module units.
Michael137 wrote:
Isn't this just the `DeclContext` that's used for lookup? Do we need to mention
namespaces and multiple modules here? Maybe we can leave that for the
`NamedModule` description
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,18 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
- /// \return \c true if any declarations might have been found, \c false if
- /// we definitely have no declarations with tbis name.
+ /// \param DC since the same namespace can appear in multiple module units.
+ /// \param Name the name of the declarations to find.
+ /// \param NamedModule find declarations visible to the given module
+ /// \c NamedModule . This may be different from owning module of \c DC since
+ /// there are declarations (e.g., namespace declaration) can appear in
+ /// multiple modules. \return \c true if any declarations might have been
+ /// found, \c false if we definitely have no declarations with tbis name.
Michael137 wrote:
```suggestion
/// multiple modules.
///
/// \return \c true if any declarations might have been found, and \c false
/// if we definitely have no declarations with this name.
```
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Implement (SB)Function::GetInstructions for discontinuous functions (PR #122933)
https://github.com/labath created
https://github.com/llvm/llvm-project/pull/122933
The main change is to permit the disassembler class to process/store multiple
(discontinuous) ranges of addresses. The result is not ambiguous because each
instruction knows its size (in addition to its address), so we can check for
discontinuity by looking at whether the next instruction begins where the
previous ends.
This patch doesn't handle the "disassemble" CLI command, which uses a more
elaborate mechanism for disassembling and printing instructions.
>From dd5dba70fe99d2510e9e1903b7f1f9a141f1572d Mon Sep 17 00:00:00 2001
From: Pavel Labath
Date: Tue, 14 Jan 2025 17:17:28 +0100
Subject: [PATCH] [lldb] Implement (SB)Function::GetInstructions for
discontinuous functions
The main change is to permit the disassembler class to process/store
multiple (discontinuous) ranges of addresses. The result is not
ambiguous because each instruction knows its size (in addition to its
address), so we can check for discontinuity by looking at whether the
next instruction begins where the previous ends.
This patch doesn't handle the "disassemble" CLI command, which uses a
more elaborate mechanism for dissassembling and printing instructions.
---
lldb/include/lldb/Core/Disassembler.h | 11 ++--
lldb/source/API/SBFunction.cpp| 2 +-
lldb/source/API/SBInstructionList.cpp | 8 ++
lldb/source/Core/Disassembler.cpp | 27 ---
lldb/source/Symbol/Function.cpp | 2 +-
.../Python/sb_function_ranges.s | 11
6 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/lldb/include/lldb/Core/Disassembler.h
b/lldb/include/lldb/Core/Disassembler.h
index e0ad4316e02497..21bacb14f9b25b 100644
--- a/lldb/include/lldb/Core/Disassembler.h
+++ b/lldb/include/lldb/Core/Disassembler.h
@@ -428,7 +428,7 @@ class Disassembler : public
std::enable_shared_from_this,
static lldb::DisassemblerSP
DisassembleRange(const ArchSpec &arch, const char *plugin_name,
const char *flavor, const char *cpu, const char *features,
- Target &target, const AddressRange &disasm_range,
+ Target &target, llvm::ArrayRef disasm_ranges,
bool force_live_memory = false);
static lldb::DisassemblerSP
@@ -460,7 +460,11 @@ class Disassembler : public
std::enable_shared_from_this,
size_t ParseInstructions(Target &target, Address address, Limit limit,
Stream *error_strm_ptr,
- bool force_live_memory = false);
+ bool force_live_memory = false) {
+m_instruction_list.Clear();
+return AppendInstructions(target, address, limit, error_strm_ptr,
+ force_live_memory);
+ }
virtual size_t DecodeInstructions(const Address &base_addr,
const DataExtractor &data,
@@ -480,6 +484,9 @@ class Disassembler : public
std::enable_shared_from_this,
const char *flavor) = 0;
protected:
+ size_t AppendInstructions(Target &target, Address address, Limit limit,
+Stream *error_strm_ptr, bool force_live_memory);
+
// SourceLine and SourceLinesToDisplay structures are only used in the mixed
// source and assembly display methods internal to this class.
diff --git a/lldb/source/API/SBFunction.cpp b/lldb/source/API/SBFunction.cpp
index 414eccc357c0e4..d07594c2e8c010 100644
--- a/lldb/source/API/SBFunction.cpp
+++ b/lldb/source/API/SBFunction.cpp
@@ -127,7 +127,7 @@ SBInstructionList SBFunction::GetInstructions(SBTarget
target,
sb_instructions.SetDisassembler(Disassembler::DisassembleRange(
module_sp->GetArchitecture(), nullptr, flavor,
target_sp->GetDisassemblyCPU(), target_sp->GetDisassemblyFeatures(),
- *target_sp, m_opaque_ptr->GetAddressRange(), force_live_memory));
+ *target_sp, m_opaque_ptr->GetAddressRanges(), force_live_memory));
}
}
return sb_instructions;
diff --git a/lldb/source/API/SBInstructionList.cpp
b/lldb/source/API/SBInstructionList.cpp
index 3f37b984cb4627..5747ae0366ec30 100644
--- a/lldb/source/API/SBInstructionList.cpp
+++ b/lldb/source/API/SBInstructionList.cpp
@@ -151,6 +151,10 @@ bool SBInstructionList::GetDescription(Stream &sref) {
FormatEntity::Parse("${addr}: ", format);
SymbolContext sc;
SymbolContext prev_sc;
+
+ // Expected address of the next instruction. Used to print an empty line
+ // for non-contiguous blocks of insns.
+ std::optional next_addr;
for (size_t i = 0; i < num_instructions; ++i) {
Instruction *inst =
m_opaque_sp->GetInstructionList().GetInstructionAtIndex(i).get();
@@ -165,10 +169,14 @@ bool SBInstructionList::GetDescription(Stream &sref) {
addr, eSymbolContextEverything, sc);
}
+
[Lldb-commits] [lldb] [lldb] Implement (SB)Function::GetInstructions for discontinuous functions (PR #122933)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Pavel Labath (labath)
Changes
The main change is to permit the disassembler class to process/store multiple
(discontinuous) ranges of addresses. The result is not ambiguous because each
instruction knows its size (in addition to its address), so we can check for
discontinuity by looking at whether the next instruction begins where the
previous ends.
This patch doesn't handle the "disassemble" CLI command, which uses a more
elaborate mechanism for disassembling and printing instructions.
---
Full diff: https://github.com/llvm/llvm-project/pull/122933.diff
6 Files Affected:
- (modified) lldb/include/lldb/Core/Disassembler.h (+9-2)
- (modified) lldb/source/API/SBFunction.cpp (+1-1)
- (modified) lldb/source/API/SBInstructionList.cpp (+8)
- (modified) lldb/source/Core/Disassembler.cpp (+11-16)
- (modified) lldb/source/Symbol/Function.cpp (+1-1)
- (modified) lldb/test/Shell/ScriptInterpreter/Python/sb_function_ranges.s
(+11)
``diff
diff --git a/lldb/include/lldb/Core/Disassembler.h
b/lldb/include/lldb/Core/Disassembler.h
index e0ad4316e02497..21bacb14f9b25b 100644
--- a/lldb/include/lldb/Core/Disassembler.h
+++ b/lldb/include/lldb/Core/Disassembler.h
@@ -428,7 +428,7 @@ class Disassembler : public
std::enable_shared_from_this,
static lldb::DisassemblerSP
DisassembleRange(const ArchSpec &arch, const char *plugin_name,
const char *flavor, const char *cpu, const char *features,
- Target &target, const AddressRange &disasm_range,
+ Target &target, llvm::ArrayRef disasm_ranges,
bool force_live_memory = false);
static lldb::DisassemblerSP
@@ -460,7 +460,11 @@ class Disassembler : public
std::enable_shared_from_this,
size_t ParseInstructions(Target &target, Address address, Limit limit,
Stream *error_strm_ptr,
- bool force_live_memory = false);
+ bool force_live_memory = false) {
+m_instruction_list.Clear();
+return AppendInstructions(target, address, limit, error_strm_ptr,
+ force_live_memory);
+ }
virtual size_t DecodeInstructions(const Address &base_addr,
const DataExtractor &data,
@@ -480,6 +484,9 @@ class Disassembler : public
std::enable_shared_from_this,
const char *flavor) = 0;
protected:
+ size_t AppendInstructions(Target &target, Address address, Limit limit,
+Stream *error_strm_ptr, bool force_live_memory);
+
// SourceLine and SourceLinesToDisplay structures are only used in the mixed
// source and assembly display methods internal to this class.
diff --git a/lldb/source/API/SBFunction.cpp b/lldb/source/API/SBFunction.cpp
index 414eccc357c0e4..d07594c2e8c010 100644
--- a/lldb/source/API/SBFunction.cpp
+++ b/lldb/source/API/SBFunction.cpp
@@ -127,7 +127,7 @@ SBInstructionList SBFunction::GetInstructions(SBTarget
target,
sb_instructions.SetDisassembler(Disassembler::DisassembleRange(
module_sp->GetArchitecture(), nullptr, flavor,
target_sp->GetDisassemblyCPU(), target_sp->GetDisassemblyFeatures(),
- *target_sp, m_opaque_ptr->GetAddressRange(), force_live_memory));
+ *target_sp, m_opaque_ptr->GetAddressRanges(), force_live_memory));
}
}
return sb_instructions;
diff --git a/lldb/source/API/SBInstructionList.cpp
b/lldb/source/API/SBInstructionList.cpp
index 3f37b984cb4627..5747ae0366ec30 100644
--- a/lldb/source/API/SBInstructionList.cpp
+++ b/lldb/source/API/SBInstructionList.cpp
@@ -151,6 +151,10 @@ bool SBInstructionList::GetDescription(Stream &sref) {
FormatEntity::Parse("${addr}: ", format);
SymbolContext sc;
SymbolContext prev_sc;
+
+ // Expected address of the next instruction. Used to print an empty line
+ // for non-contiguous blocks of insns.
+ std::optional next_addr;
for (size_t i = 0; i < num_instructions; ++i) {
Instruction *inst =
m_opaque_sp->GetInstructionList().GetInstructionAtIndex(i).get();
@@ -165,10 +169,14 @@ bool SBInstructionList::GetDescription(Stream &sref) {
addr, eSymbolContextEverything, sc);
}
+if (next_addr && addr != next_addr)
+ sref.EOL();
inst->Dump(&sref, max_opcode_byte_size, true, false,
/*show_control_flow_kind=*/false, nullptr, &sc, &prev_sc,
&format, 0);
sref.EOL();
+next_addr = addr;
+next_addr->Slide(inst->GetOpcode().GetByteSize());
}
return true;
}
diff --git a/lldb/source/Core/Disassembler.cpp
b/lldb/source/Core/Disassembler.cpp
index 68e52144eb6ef8..ed6a008a29fef5 100644
--- a/lldb/source/Core/Disassembler.cpp
+++ b/lldb/source/Core/Disassembler.cpp
@@ -123,22 +123,19 @@ static Address ResolveAddr
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
llvmbot wrote: @llvm/pr-subscribers-clangd Author: None (Sirraide) Changes ## Changes tl;dr: The names are inaccurate and continue to cause confusion. This pr currently makes the following changes: - Rename `isAnyPointerType()` to `isPointerOrObjCObjectPointerType()`. - Rename `getPointeeOrArrayElementType()` to `getPointerOrObjCPointerOrArrayElementType()`. - Introduce `getPointerLikeOrArrayElementType()` which actually *is* a superset of the functionality that `getPointeeType()` provides (I don’t think we can call this `getPointeeOrArrayElementType()` because that would effectively just mean that the behaviour of this function changes all of a sudden, which may cause even more confusion for people that are not aware that we’re making this change). A function like this that actually supports member pointers is needed for #121525. - Elaborate on what types `getPointeeType()` actually supports in a comment. `getPointeeType()` actually ends up being fine imo because it *does* actually handle anything that could reasonably be conceived of as having a ‘pointee’. ## Open Questions - The names for the first two are rather verbose; I’m open to suggestions as to better names for these functions since that was the best that I managed to come up with... - I’ve already discussed this somewhat with @AaronBallman and @cor3ntin, and I think that we probably don’t want to introduce any new helpers like `isAnyPointerType()` that claim to handle ‘all pointer types’, mainly because a lot of the calls to `isAnyPointerType()` are currently of the form `if (Ty->isAnyPointerType() || Ty->someOtherPredicate())`, where `someOtherPredicate()` may check for `ReferenceType`, `MemberPointerType`, etc. It seems that nearly every call site is different in what ‘pointer-like types’ it cares about, so a general helper is unlikely to be of any use pretty much ever. - I’m planning to do a general clean-up pass and look at all call sites of what used to be `isAnyPointerType()` to see if there is anything weird—so far, two instances of rather obvious dead code have surfaced as a result of the renaming (see below)—but my plan is to do that as a follow-up pr. - Additionally, there are a few places we could probably clean up by either introducing or using newer helper functions, e.g. we now have `isPointerOrReferenceType()`, so it would be possible to replace every instance of `Ty->isPointerType() || Ty->isReferenceType()` with `Ty->isPointerOrReferenceType()` and additionally introduce new helpers for common combinations of these predicates. At the same time, that sounds a bit like a reformatting pass with extra steps, and we usually tend to eschew these because they interact poorly with `git blame` from what I recall, so I’m not sure if that’s a good idea. - @AaronBallman There is an AST matcher with the name `isAnyPointer()`, which uses `isAnyPointerType()`. I’m not sure what exactly we want to do with that one. ## Background In the `Type` class, we currently have the following function: ```c++ bool isAnyPointerType() const; ``` which, one might reasonably assume, ought to return `true` if `this` is ‘any pointer type’, whatever that means. It turns out that what that actually ends up meaning is: ``` // Any C pointer or ObjC object pointer ``` That is, it does not include - Member pointers, - Block pointers, - `nullptr_t`. Of course, one might argue that e.g. member pointers aren’t actually pointers but offsets, which is true, but we still *call* them `MemberPointerType`s, so by name alone, they are still ‘a kind of pointer’. Searching for occurrences yields several cases where someone has fallen for this and misunderstood what ‘any pointer type’ was actually supposed to mean. I’ve renamed it to `isPointerOrObjCObjectPointerType()`, so these misuses end up being rather apparent. There seem to be at least two places that are currently in the code base where someone got confused about this: - Here, we end up checking if `Pointee` is a pointer or Objective-C pointer... or Objective-C pointer. https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/Sema/SemaAPINotes.cpp#L51-L52 - Here, it would seem that both of these `if` statements together end up being functionally equivalent to `if (!Ty->isObjectPointerType()) return false;` https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/ARCMigrate/ObjCMT.cpp#L1044-L1050 Additionally, I can recall several instances of me either reading or writing code that uses `isAnyPointerType()` and then getting confused why something wasn’t working properly, and I’ve heard similar sentiment from others. Another possible instance of that might be `getPointeeOrArrayElementType()`. You’d think based on its name that it’s an extension of `getPointeeType()` that also handles arrays, but that’s wrong: the former calls `isAnyPointerType()` before delegating to `getPointeeType()`, w
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
llvmbot wrote: @llvm/pr-subscribers-clang Author: None (Sirraide) Changes ## Changes tl;dr: The names are inaccurate and continue to cause confusion. This pr currently makes the following changes: - Rename `isAnyPointerType()` to `isPointerOrObjCObjectPointerType()`. - Rename `getPointeeOrArrayElementType()` to `getPointerOrObjCPointerOrArrayElementType()`. - Introduce `getPointerLikeOrArrayElementType()` which actually *is* a superset of the functionality that `getPointeeType()` provides (I don’t think we can call this `getPointeeOrArrayElementType()` because that would effectively just mean that the behaviour of this function changes all of a sudden, which may cause even more confusion for people that are not aware that we’re making this change). A function like this that actually supports member pointers is needed for #121525. - Elaborate on what types `getPointeeType()` actually supports in a comment. `getPointeeType()` actually ends up being fine imo because it *does* actually handle anything that could reasonably be conceived of as having a ‘pointee’. ## Open Questions - The names for the first two are rather verbose; I’m open to suggestions as to better names for these functions since that was the best that I managed to come up with... - I’ve already discussed this somewhat with @AaronBallman and @cor3ntin, and I think that we probably don’t want to introduce any new helpers like `isAnyPointerType()` that claim to handle ‘all pointer types’, mainly because a lot of the calls to `isAnyPointerType()` are currently of the form `if (Ty->isAnyPointerType() || Ty->someOtherPredicate())`, where `someOtherPredicate()` may check for `ReferenceType`, `MemberPointerType`, etc. It seems that nearly every call site is different in what ‘pointer-like types’ it cares about, so a general helper is unlikely to be of any use pretty much ever. - I’m planning to do a general clean-up pass and look at all call sites of what used to be `isAnyPointerType()` to see if there is anything weird—so far, two instances of rather obvious dead code have surfaced as a result of the renaming (see below)—but my plan is to do that as a follow-up pr. - Additionally, there are a few places we could probably clean up by either introducing or using newer helper functions, e.g. we now have `isPointerOrReferenceType()`, so it would be possible to replace every instance of `Ty->isPointerType() || Ty->isReferenceType()` with `Ty->isPointerOrReferenceType()` and additionally introduce new helpers for common combinations of these predicates. At the same time, that sounds a bit like a reformatting pass with extra steps, and we usually tend to eschew these because they interact poorly with `git blame` from what I recall, so I’m not sure if that’s a good idea. - @AaronBallman There is an AST matcher with the name `isAnyPointer()`, which uses `isAnyPointerType()`. I’m not sure what exactly we want to do with that one. ## Background In the `Type` class, we currently have the following function: ```c++ bool isAnyPointerType() const; ``` which, one might reasonably assume, ought to return `true` if `this` is ‘any pointer type’, whatever that means. It turns out that what that actually ends up meaning is: ``` // Any C pointer or ObjC object pointer ``` That is, it does not include - Member pointers, - Block pointers, - `nullptr_t`. Of course, one might argue that e.g. member pointers aren’t actually pointers but offsets, which is true, but we still *call* them `MemberPointerType`s, so by name alone, they are still ‘a kind of pointer’. Searching for occurrences yields several cases where someone has fallen for this and misunderstood what ‘any pointer type’ was actually supposed to mean. I’ve renamed it to `isPointerOrObjCObjectPointerType()`, so these misuses end up being rather apparent. There seem to be at least two places that are currently in the code base where someone got confused about this: - Here, we end up checking if `Pointee` is a pointer or Objective-C pointer... or Objective-C pointer. https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/Sema/SemaAPINotes.cpp#L51-L52 - Here, it would seem that both of these `if` statements together end up being functionally equivalent to `if (!Ty->isObjectPointerType()) return false;` https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/ARCMigrate/ObjCMT.cpp#L1044-L1050 Additionally, I can recall several instances of me either reading or writing code that uses `isAnyPointerType()` and then getting confused why something wasn’t working properly, and I’ve heard similar sentiment from others. Another possible instance of that might be `getPointeeOrArrayElementType()`. You’d think based on its name that it’s an extension of `getPointeeType()` that also handles arrays, but that’s wrong: the former calls `isAnyPointerType()` before delegating to `getPointeeType()`, wh
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
llvmbot wrote: @llvm/pr-subscribers-backend-risc-v Author: None (Sirraide) Changes ## Changes tl;dr: The names are inaccurate and continue to cause confusion. This pr currently makes the following changes: - Rename `isAnyPointerType()` to `isPointerOrObjCObjectPointerType()`. - Rename `getPointeeOrArrayElementType()` to `getPointerOrObjCPointerOrArrayElementType()`. - Introduce `getPointerLikeOrArrayElementType()` which actually *is* a superset of the functionality that `getPointeeType()` provides (I don’t think we can call this `getPointeeOrArrayElementType()` because that would effectively just mean that the behaviour of this function changes all of a sudden, which may cause even more confusion for people that are not aware that we’re making this change). A function like this that actually supports member pointers is needed for #121525. - Elaborate on what types `getPointeeType()` actually supports in a comment. `getPointeeType()` actually ends up being fine imo because it *does* actually handle anything that could reasonably be conceived of as having a ‘pointee’. ## Open Questions - The names for the first two are rather verbose; I’m open to suggestions as to better names for these functions since that was the best that I managed to come up with... - I’ve already discussed this somewhat with @AaronBallman and @cor3ntin, and I think that we probably don’t want to introduce any new helpers like `isAnyPointerType()` that claim to handle ‘all pointer types’, mainly because a lot of the calls to `isAnyPointerType()` are currently of the form `if (Ty->isAnyPointerType() || Ty->someOtherPredicate())`, where `someOtherPredicate()` may check for `ReferenceType`, `MemberPointerType`, etc. It seems that nearly every call site is different in what ‘pointer-like types’ it cares about, so a general helper is unlikely to be of any use pretty much ever. - I’m planning to do a general clean-up pass and look at all call sites of what used to be `isAnyPointerType()` to see if there is anything weird—so far, two instances of rather obvious dead code have surfaced as a result of the renaming (see below)—but my plan is to do that as a follow-up pr. - Additionally, there are a few places we could probably clean up by either introducing or using newer helper functions, e.g. we now have `isPointerOrReferenceType()`, so it would be possible to replace every instance of `Ty->isPointerType() || Ty->isReferenceType()` with `Ty->isPointerOrReferenceType()` and additionally introduce new helpers for common combinations of these predicates. At the same time, that sounds a bit like a reformatting pass with extra steps, and we usually tend to eschew these because they interact poorly with `git blame` from what I recall, so I’m not sure if that’s a good idea. - @AaronBallman There is an AST matcher with the name `isAnyPointer()`, which uses `isAnyPointerType()`. I’m not sure what exactly we want to do with that one. ## Background In the `Type` class, we currently have the following function: ```c++ bool isAnyPointerType() const; ``` which, one might reasonably assume, ought to return `true` if `this` is ‘any pointer type’, whatever that means. It turns out that what that actually ends up meaning is: ``` // Any C pointer or ObjC object pointer ``` That is, it does not include - Member pointers, - Block pointers, - `nullptr_t`. Of course, one might argue that e.g. member pointers aren’t actually pointers but offsets, which is true, but we still *call* them `MemberPointerType`s, so by name alone, they are still ‘a kind of pointer’. Searching for occurrences yields several cases where someone has fallen for this and misunderstood what ‘any pointer type’ was actually supposed to mean. I’ve renamed it to `isPointerOrObjCObjectPointerType()`, so these misuses end up being rather apparent. There seem to be at least two places that are currently in the code base where someone got confused about this: - Here, we end up checking if `Pointee` is a pointer or Objective-C pointer... or Objective-C pointer. https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/Sema/SemaAPINotes.cpp#L51-L52 - Here, it would seem that both of these `if` statements together end up being functionally equivalent to `if (!Ty->isObjectPointerType()) return false;` https://github.com/llvm/llvm-project/blob/1c26eb363147bd10be797d3d77603fb793b2bc0f/clang/lib/ARCMigrate/ObjCMT.cpp#L1044-L1050 Additionally, I can recall several instances of me either reading or writing code that uses `isAnyPointerType()` and then getting confused why something wasn’t working properly, and I’ve heard similar sentiment from others. Another possible instance of that might be `getPointeeOrArrayElementType()`. You’d think based on its name that it’s an extension of `getPointeeType()` that also handles arrays, but that’s wrong: the former calls `isAnyPointerType()` before delegating to `getPointeeTy
[Lldb-commits] [lldb] 428c876 - [libc++] Stop copying headers to the build directory (#115380)
Author: Alexander Richardson
Date: 2025-01-14T08:40:04-05:00
New Revision: 428c8767ae997b0f726c0b40160ea8172551babf
URL:
https://github.com/llvm/llvm-project/commit/428c8767ae997b0f726c0b40160ea8172551babf
DIFF:
https://github.com/llvm/llvm-project/commit/428c8767ae997b0f726c0b40160ea8172551babf.diff
LOG: [libc++] Stop copying headers to the build directory (#115380)
This was needed before https://github.com/llvm/llvm-project/pull/115077
since the compiler-rt test build made assumptions about the build
layout of libc++ and libc++abi, but now they link against a local
installation of these libraries so we no longer need this workaround.
Added:
Modified:
libcxx/CMakeLists.txt
libcxxabi/CMakeLists.txt
libcxxabi/include/CMakeLists.txt
lldb/test/CMakeLists.txt
lldb/utils/lldb-dotest/CMakeLists.txt
Removed:
diff --git a/libcxx/CMakeLists.txt b/libcxx/CMakeLists.txt
index abe12c2805a7cf..5fab3a99e9e862 100644
--- a/libcxx/CMakeLists.txt
+++ b/libcxx/CMakeLists.txt
@@ -414,15 +414,16 @@ set(LIBCXX_INSTALL_MODULES_DIR "share/libc++/v1" CACHE
STRING
set(LIBCXX_SHARED_OUTPUT_NAME "c++" CACHE STRING "Output name for the shared
libc++ runtime library.")
set(LIBCXX_STATIC_OUTPUT_NAME "c++" CACHE STRING "Output name for the static
libc++ runtime library.")
+set(LIBCXX_GENERATED_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++/v1")
+set(LIBCXX_GENERATED_MODULE_DIR "${LIBCXX_BINARY_DIR}/modules/c++/v1")
+
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
set(LIBCXX_TARGET_SUBDIR ${LLVM_DEFAULT_TARGET_TRIPLE})
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBCXX_TARGET_SUBDIR /${LIBCXX_LIBDIR_SUBDIR})
endif()
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LIBCXX_TARGET_SUBDIR})
- set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
- set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
- set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR
"${LLVM_BINARY_DIR}/include/${LIBCXX_TARGET_SUBDIR}/c++/v1")
+ set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR
"${LIBCXX_BINARY_DIR}/include/${LIBCXX_TARGET_SUBDIR}/c++/v1")
set(LIBCXX_INSTALL_LIBRARY_DIR
lib${LLVM_LIBDIR_SUFFIX}/${LIBCXX_TARGET_SUBDIR} CACHE STRING
"Path where built libc++ libraries should be installed.")
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR
"${CMAKE_INSTALL_INCLUDEDIR}/${LIBCXX_TARGET_SUBDIR}/c++/v1" CACHE STRING
@@ -431,12 +432,8 @@ if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
else()
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
-set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
-set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
else()
set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
-set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
-set(LIBCXX_GENERATED_MODULE_DIR "${CMAKE_BINARY_DIR}/modules/c++/v1")
endif()
set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX} CACHE STRING
diff --git a/libcxxabi/CMakeLists.txt b/libcxxabi/CMakeLists.txt
index 6dcfc51e553213..4da42faad67413 100644
--- a/libcxxabi/CMakeLists.txt
+++ b/libcxxabi/CMakeLists.txt
@@ -91,12 +91,6 @@ set(LIBCXXABI_STATIC_OUTPUT_NAME "c++abi" CACHE STRING
"Output name for the stat
set(LIBCXXABI_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1" CACHE
STRING "Path to install the libc++abi headers at.")
-if(LLVM_LIBRARY_OUTPUT_INTDIR)
- set(LIBCXXABI_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
-else()
- set(LIBCXXABI_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
-endif()
-
set(LIBCXXABI_LIBCXX_LIBRARY_PATH "" CACHE PATH "The path to libc++ library.")
set(LIBCXXABI_LIBRARY_VERSION "1.0" CACHE STRING
"Version of libc++abi. This will be reflected in the name of the shared \
diff --git a/libcxxabi/include/CMakeLists.txt
b/libcxxabi/include/CMakeLists.txt
index 5b1cc2545016ec..0deb7b1eb9e715 100644
--- a/libcxxabi/include/CMakeLists.txt
+++ b/libcxxabi/include/CMakeLists.txt
@@ -3,20 +3,7 @@ set(files
cxxabi.h
)
-foreach(f ${files})
- set(src "${CMAKE_CURRENT_SOURCE_DIR}/${f}")
- set(dst "${LIBCXXABI_GENERATED_INCLUDE_DIR}/${f}")
- add_custom_command(OUTPUT ${dst}
-DEPENDS ${src}
-COMMAND ${CMAKE_COMMAND} -E copy_if_
diff erent ${src} ${dst}
-COMMENT "Copying CXXABI header ${f}")
- list(APPEND _all_includes "${dst}")
-endforeach()
-
-add_custom_target(generate-cxxabi-headers ALL DEPENDS ${_all_includes})
-
add_library(cxxabi-headers INTERFACE)
-add_dependencies(cxxabi-headers generate-cxxabi-headers)
target_include_directories(cxxabi-headers INTERFACE
"${CMAKE_CURRENT_SOURCE_DIR}")
if (LIBCXXABI_INSTALL_HEADERS)
diff --git a/lldb/test/CMakeLists.txt b/lldb/test/CMakeLists.txt
index 6449ac5a9247f6..d51b18
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
https://github.com/ldionne closed https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
ldionne wrote: A bunch of CI jobs were triggered because of my faulty rebase, but the necessary jobs seems to have passed. What's still pending are some release jobs which normally don't run on PRs, and the documentation job which fails for an unrelated reason (`clang-tools-extra`). Merging. https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
ldionne wrote: LLDB, please ping us if you encounter problems after we merge this patch. https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
llvm-ci wrote: LLVM Buildbot has detected a new failure on builder `sanitizer-aarch64-linux` running on `sanitizer-buildbot8` while building `libcxx,libcxxabi,lldb` at step 2 "annotate". Full details are available at: https://lab.llvm.org/buildbot/#/builders/51/builds/9056 Here is the relevant piece of the build log for the reference ``` Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure) ... -- Performing Test HAVE_CXX_ATOMICS_WITH_LIB - Failed -- Configuring incomplete, errors occurred! CMake Error at cmake/modules/CheckAtomic.cmake:56 (message): Host compiler must support std::atomic! Call Stack (most recent call first): cmake/config-ix.cmake:418 (include) CMakeLists.txt:973 (include) [3005/3065] Building CXX object compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.aarch64.dir/asan_interceptors.cpp.o FAILED: compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64.o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64.o cd /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64 && FLAGS=-march=armv8-a CLANG=/home/b/sanitizer-aarch64-linux/build/build_default/./bin/clang /home/b/sanitizer-aarch64-linux/build/llvm-project/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64.o ninja: build stopped: subcommand failed. FAILED: runtimes/runtimes-stamps/runtimes-build /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-stamps/runtimes-build cd /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins && /usr/bin/cmake --build . ninja: build stopped: subcommand failed. How to reproduce locally: https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild @@@STEP_FAILURE@@@ @@@BUILD_STEP test compiler-rt symbolizer@@@ ninja: Entering directory `build_default' [0/5] Performing build step for 'builtins' ninja: no work to do. [1/5] No install step for 'builtins' [3/5] Completed 'builtins' [3/5] Performing configure step for 'runtimes' Not searching for unused variables given on the command line. loading initial cache file /home/b/sanitizer-aarch64-linux/build/build_default/projects/runtimes/tmp/runtimes-cache-Release.cmake -- Performing bootstrapping runtimes build. CMake Deprecation Warning at /home/b/sanitizer-aarch64-linux/build/llvm-project/cmake/Modules/CMakePolicy.cmake:6 (cmake_policy): The OLD behavior for policy CMP0116 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. Call Stack (most recent call first): CMakeLists.txt:18 (include) -- Building with -fPIC -- LLVM host triple: aarch64-unknown-linux-gnu -- LLVM default target triple: aarch64-unknown-linux-gnu -- Using libunwind testing configuration: /home/b/sanitizer-aarch64-linux/build/llvm-project/libunwind/test/configs/llvm-libunwind-shared.cfg.in -- Failed to locate sphinx-build executable (missing: SPHINX_EXECUTABLE) -- Using libc++abi testing configuration: /home/b/sanitizer-aarch64-linux/build/llvm-project/libcxxabi/test/configs/llvm-libc++abi-shared.cfg.in -- Using libc++ testing configuration: /home/b/sanitizer-aarch64-linux/build/llvm-project/libcxx/test/configs/llvm-libc++-shared.cfg.in Step 9 (build compiler-rt symbolizer) failure: build compiler-rt symbolizer (failure) ... -- Looking for __atomic_fetch_add_4 in atomic - found -- Performing Test HAVE_CXX_ATOMICS_WITH_LIB -- Performing Test HAVE_CXX_ATOMICS_WITH_LIB - Failed -- Configuring incomplete, errors occurred! CMake Error at cmake/modules/CheckAtomic.cmake:56 (message): Host compiler must support std::atomic! Call Stack (most recent call first): cmake/config-ix.cmake:418 (include) CMakeLists.txt:973 (include) [3005/3065] Building CXX object compiler-rt/lib/asan/CMakeFiles/RTAsan_dynamic.aarch64.dir/asan_interceptors.cpp.o FAILED: compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64.o /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64.o cd /home/b/sanitizer-aarch64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/sanitizer_common/symbolizer/RTSanitizerCommonSymbolizerInternal.aarch64 && FLAGS=-march=armv8-a CLANG=/home/b/sanitizer-aarch64-linux/build/bui
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/122887
>From 0555df5f2bd726904e1ac21f44c9623aa057f831 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 26 Dec 2024 16:00:51 +0800
Subject: [PATCH] [C++20] [Modules] Support module level lookup
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.
Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.
Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.
In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as the key.
And refactored `DeclContext::lookup()` method to take the module
information. So that a lookup in a DeclContext won't load declarations
that are local to **other** modules.
And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.
BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.
This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.
---
clang/docs/ReleaseNotes.rst | 2 +
clang/include/clang/AST/DeclBase.h| 10 +
clang/include/clang/AST/ExternalASTMerger.h | 3 +-
clang/include/clang/AST/ExternalASTSource.h | 12 +-
.../clang/Sema/MultiplexExternalSemaSource.h | 3 +-
.../include/clang/Serialization/ASTBitCodes.h | 6 +
clang/include/clang/Serialization/ASTReader.h | 32 +-
clang/include/clang/Serialization/ASTWriter.h | 16 +-
clang/lib/AST/DeclBase.cpp| 23 +-
clang/lib/AST/ExternalASTMerger.cpp | 3 +-
clang/lib/AST/ExternalASTSource.cpp | 6 +-
clang/lib/Interpreter/CodeCompletion.cpp | 6 +-
.../lib/Sema/MultiplexExternalSemaSource.cpp | 7 +-
clang/lib/Serialization/ASTReader.cpp | 195 ++---
clang/lib/Serialization/ASTReaderDecl.cpp | 69 +++--
clang/lib/Serialization/ASTReaderInternals.h | 72 -
clang/lib/Serialization/ASTWriter.cpp | 273 ++
clang/lib/Serialization/ASTWriterDecl.cpp | 13 +-
.../basic.scope/basic.scope.namespace/p2.cpp | 4 +-
.../test/CXX/module/basic/basic.link/p2.cppm | 3 +-
clang/test/CXX/module/module.import/p2.cpp| 10 +-
clang/test/CXX/module/module.interface/p7.cpp | 10 +-
clang/test/CXX/module/module.reach/p5.cpp | 3 +-
.../Reachability-template-default-arg.cpp | 3 +-
clang/test/Modules/cxx20-10-1-ex2.cpp | 3 +-
clang/test/Modules/deduction-guide3.cppm | 4 +-
.../Modules/module-local-with-templates.cppm | 79 +
clang/test/Modules/pr90154.cppm | 25 ++
clang/unittests/AST/ExternalASTSourceTest.cpp | 3 +-
.../Plugins/ExpressionParser/Clang/ASTUtils.h | 10 +-
.../ExpressionParser/Clang/ClangASTSource.cpp | 3 +-
.../ExpressionParser/Clang/ClangASTSource.h | 8 +-
.../Clang/ClangExternalASTSourceCallbacks.cpp | 3 +-
.../Clang/ClangExternalASTSourceCallbacks.h | 3 +-
.../AppleObjCRuntime/AppleObjCDeclVendor.cpp | 3 +-
35 files changed, 733 insertions(+), 195 deletions(-)
create mode 100644 clang/test/Modules/module-local-with-templates.cppm
create mode 100644 clang/test/Modules/pr90154.cppm
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9eeb872aa57d79..142ed6e19b0a79 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -316,6 +316,8 @@ C++23 Feature Support
C++20 Feature Support
^
+- Implemented module level lookup for C++20 modules. (#GH90154)
+
Resolutions to C++ Defect Reports
^
diff --git a/clang/include/clang/AST/DeclBase.h
b/clang/include/clang/AST/DeclBase.h
index 77abd8b657a616..8686c2fe95dd6d 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -836,6 +836,10 @@ class alignas(8) Decl {
return isFromASTFile() ? getImportedOwningModule() :
getLocalOwningModule();
}
+ /// G
[Lldb-commits] [lldb] [lldb] Remove unfiltered stop reason propagation from StopInfoMachException (PR #122817)
https://github.com/jimingham approved this pull request. LGTM. Adding an OS plugin is a user gesture, and changes the view of the threads in the process as its primary action. So I agree it's reasonable that the user who adds the OS plugin would know they have to reset their thread specific breakpoints to handle the new view. https://github.com/llvm/llvm-project/pull/122817 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
cor3ntin wrote: Thanks for working on this. A few comment: `getPointerLikeOrArrayElementType` is not used, and I'm rather concerned by what it does. Removing pointiness in some cases seem dangerous, and not super useful... Renaming `getPointeeOrArrayElementType` to `getPointerOrArrayElementType` seems wrong. However, if we put an assert in these function that the type is indeed a pointer or an array, how much code break? I suspect not much, and we could fix the caller. ie this function is too magic/does too much. I would rather not use `Like` in any of the name because in C++ this is often use to mean "a type that behaves like this core construct". ie `unique_ptr` is pointer-like https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
Sirraide wrote: > That’s fair, I don’t think it’s crucial to add that or anything. If anything the pr in question can either add that or put that somewhere else; I’ll remove that function from this pr. https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
Sirraide wrote: > Not confused. renaming `getPointeeFoo` to `getPointerBar` does not seem > correct, especially as `getPointeeOrArrayElementType` does indeed return a > pointee. Ah, I see, in that case the only other name I could think of would be something like `getPointerOrObjCPointerPointeeOrArrayElementType`. I personally was reading `getPointerOrObjCPointerOrArrayElementType()` as ‘get the element type of a pointer, objc pointer, or array’. https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
Sirraide wrote: (just removed the last two commits that only added that function) https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
cor3ntin wrote: > Ah, I think you’re confusing two functions there: > `getPointeeOrArrayElementType()` is being renamed to > `getPointerOrObjCPointerOrArrayElementType()`, not > `getPointerOrArrayElementType()`. Not confused. renaming `getPointeeFoo` to `getPointerBar` does not seem correct, especially as `getPointeeOrArrayElementType` does indeed return a pointee. And my other point, is that there should not be a use case for "If T is a pointer give me the pointee, otherwise give me T" - which is why I'm suggesting functions returning a pointee should not accept a non-pointer type https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
arichardson wrote: I realize there are some issues with this and while it's a nice cleanup, I don't have the time right now to deal with the potential fallout (build directory can't be used as a cross-compiler out of the box). https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
@@ -511,22 +513,58 @@ ValueObjectSP
StackFrame::GetValueForVariableExpressionPath(
VariableSP &var_sp, Status &error) {
ExecutionContext exe_ctx;
CalculateExecutionContext(exe_ctx);
+
bool use_DIL = exe_ctx.GetTargetRef().GetUseDIL(&exe_ctx);
+
if (use_DIL)
return DILGetValueForVariableExpressionPath(var_expr, use_dynamic, options,
var_sp, error);
-
- return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
options,
- var_sp, error);
+ else
+return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
+ options, var_sp, error);
}
ValueObjectSP StackFrame::DILGetValueForVariableExpressionPath(
llvm::StringRef var_expr, lldb::DynamicValueType use_dynamic,
uint32_t options, lldb::VariableSP &var_sp, Status &error) {
- // This is a place-holder for the calls into the DIL parser and
- // evaluator. For now, just call the "real" frame variable implementation.
- return LegacyGetValueForVariableExpressionPath(var_expr, use_dynamic,
options,
- var_sp, error);
+ ValueObjectSP ret_val;
+ std::shared_ptr source =
+ std::make_shared(var_expr.data());
+
+ const bool check_ptr_vs_member =
+ (options & eExpressionPathOptionCheckPtrVsMember) != 0;
+ const bool no_fragile_ivar =
+ (options & eExpressionPathOptionsNoFragileObjcIvar) != 0;
+ const bool no_synth_child =
+ (options & eExpressionPathOptionsNoSyntheticChildren) != 0;
+
+ // Parse the expression.
+ Status parse_error, eval_error;
+ dil::DILParser parser(source, shared_from_this(), use_dynamic,
+!no_synth_child, !no_fragile_ivar,
check_ptr_vs_member);
+ dil::DILASTNodeUP tree = parser.Run(parse_error);
+ if (parse_error.Fail()) {
+error = std::move(parse_error);
+return ValueObjectSP();
+ }
+
+ // Evaluate the parsed expression.
+ lldb::TargetSP target = this->CalculateTarget();
+ dil::DILInterpreter interpreter(target, source, use_dynamic);
+
+ ret_val = interpreter.DILEval(tree.get(), target, eval_error);
+ if (eval_error.Fail()) {
+error = std::move(eval_error);
+return ValueObjectSP();
+ }
+
+ if (ret_val) {
+var_sp = ret_val->GetVariable();
+if (!var_sp && ret_val->GetParent()) {
+ var_sp = ret_val->GetParent()->GetVariable();
+}
cmtice wrote:
Part of the testing I'm doing on the full DIL implementation is to hard-code
GetValueForVariableExpressionPath to always use the DIL version (testing to
make sure it works as a full replacement for current implementation), then run
'ninja check-lldb' to see if everything still passes. If I remove lines
561-565 above (the part the updates var_sp) I get 6 new tests failing...
https://github.com/llvm/llvm-project/pull/120971
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 576b538 - Revert "[libc++] Stop copying headers to the build directory (#115380)"
Author: Kirill Stoimenov
Date: 2025-01-14T18:23:07Z
New Revision: 576b53801fc3d721602ae0d8377af9950f356000
URL:
https://github.com/llvm/llvm-project/commit/576b53801fc3d721602ae0d8377af9950f356000
DIFF:
https://github.com/llvm/llvm-project/commit/576b53801fc3d721602ae0d8377af9950f356000.diff
LOG: Revert "[libc++] Stop copying headers to the build directory (#115380)"
This reverts commit 428c8767ae997b0f726c0b40160ea8172551babf.
Breaks sanitizer build: https://lab.llvm.org/buildbot/#/builders/51/builds/9056
Added:
Modified:
libcxx/CMakeLists.txt
libcxxabi/CMakeLists.txt
libcxxabi/include/CMakeLists.txt
lldb/test/CMakeLists.txt
lldb/utils/lldb-dotest/CMakeLists.txt
Removed:
diff --git a/libcxx/CMakeLists.txt b/libcxx/CMakeLists.txt
index 5fab3a99e9e862..abe12c2805a7cf 100644
--- a/libcxx/CMakeLists.txt
+++ b/libcxx/CMakeLists.txt
@@ -414,16 +414,15 @@ set(LIBCXX_INSTALL_MODULES_DIR "share/libc++/v1" CACHE
STRING
set(LIBCXX_SHARED_OUTPUT_NAME "c++" CACHE STRING "Output name for the shared
libc++ runtime library.")
set(LIBCXX_STATIC_OUTPUT_NAME "c++" CACHE STRING "Output name for the static
libc++ runtime library.")
-set(LIBCXX_GENERATED_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++/v1")
-set(LIBCXX_GENERATED_MODULE_DIR "${LIBCXX_BINARY_DIR}/modules/c++/v1")
-
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
set(LIBCXX_TARGET_SUBDIR ${LLVM_DEFAULT_TARGET_TRIPLE})
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBCXX_TARGET_SUBDIR /${LIBCXX_LIBDIR_SUBDIR})
endif()
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LIBCXX_TARGET_SUBDIR})
- set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR
"${LIBCXX_BINARY_DIR}/include/${LIBCXX_TARGET_SUBDIR}/c++/v1")
+ set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+ set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
+ set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR
"${LLVM_BINARY_DIR}/include/${LIBCXX_TARGET_SUBDIR}/c++/v1")
set(LIBCXX_INSTALL_LIBRARY_DIR
lib${LLVM_LIBDIR_SUFFIX}/${LIBCXX_TARGET_SUBDIR} CACHE STRING
"Path where built libc++ libraries should be installed.")
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR
"${CMAKE_INSTALL_INCLUDEDIR}/${LIBCXX_TARGET_SUBDIR}/c++/v1" CACHE STRING
@@ -432,8 +431,12 @@ if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
else()
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
+set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+set(LIBCXX_GENERATED_MODULE_DIR "${LLVM_BINARY_DIR}/modules/c++/v1")
else()
set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
+set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
+set(LIBCXX_GENERATED_MODULE_DIR "${CMAKE_BINARY_DIR}/modules/c++/v1")
endif()
set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
set(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX} CACHE STRING
diff --git a/libcxxabi/CMakeLists.txt b/libcxxabi/CMakeLists.txt
index 4da42faad67413..6dcfc51e553213 100644
--- a/libcxxabi/CMakeLists.txt
+++ b/libcxxabi/CMakeLists.txt
@@ -91,6 +91,12 @@ set(LIBCXXABI_STATIC_OUTPUT_NAME "c++abi" CACHE STRING
"Output name for the stat
set(LIBCXXABI_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1" CACHE
STRING "Path to install the libc++abi headers at.")
+if(LLVM_LIBRARY_OUTPUT_INTDIR)
+ set(LIBCXXABI_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
+else()
+ set(LIBCXXABI_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
+endif()
+
set(LIBCXXABI_LIBCXX_LIBRARY_PATH "" CACHE PATH "The path to libc++ library.")
set(LIBCXXABI_LIBRARY_VERSION "1.0" CACHE STRING
"Version of libc++abi. This will be reflected in the name of the shared \
diff --git a/libcxxabi/include/CMakeLists.txt
b/libcxxabi/include/CMakeLists.txt
index 0deb7b1eb9e715..5b1cc2545016ec 100644
--- a/libcxxabi/include/CMakeLists.txt
+++ b/libcxxabi/include/CMakeLists.txt
@@ -3,7 +3,20 @@ set(files
cxxabi.h
)
+foreach(f ${files})
+ set(src "${CMAKE_CURRENT_SOURCE_DIR}/${f}")
+ set(dst "${LIBCXXABI_GENERATED_INCLUDE_DIR}/${f}")
+ add_custom_command(OUTPUT ${dst}
+DEPENDS ${src}
+COMMAND ${CMAKE_COMMAND} -E copy_if_
diff erent ${src} ${dst}
+COMMENT "Copying CXXABI header ${f}")
+ list(APPEND _all_includes "${dst}")
+endforeach()
+
+add_custom_target(generate-cxxabi-headers ALL DEPENDS ${_all_includes})
+
add_library(cxxabi-headers INTERFACE)
+add_dependencies(cxxabi-headers generate-cxxabi-headers)
target_include_directories(cxxabi-headers INTERFACE
"${CMAKE_CURRENT_SOURCE_DIR}")
if (LIBCXXABI_INSTALL_HEADERS)
diff --git a/lldb/test/CMakeLists.txt b/lldb/test/CMakeLists.txt
index d51b18d71f3980..6449ac5a9247f6 100644
--- a/lldb/test/CMakeLists.txt
+++ b/lldb/test/CMakeLists.txt
@@ -157,22 +157,15 @@ if(TARGET clang)
# TestFullL
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
kstoimenov wrote: @arichardson this was reverted due to sanitizer build failures: https://lab.llvm.org/buildbot/#/builders/51/builds/9056 https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
Prabhuk wrote: We are seeing a failures in our Fuchsia toolchain builders and I suspect this CL is the root cause. Overview: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8725760447541892625/overview Logs: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8725760447541892625/+/u/clang/test/stdout https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/122887
>From a259ccafe9b6f7efc740cd7203d44fd4170a25dc Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 26 Dec 2024 16:00:51 +0800
Subject: [PATCH] [C++20] [Modules] Support module level lookup
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.
Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.
Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.
In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as the key.
And refactored `DeclContext::lookup()` method to take the module
information. So that a lookup in a DeclContext won't load declarations
that are local to **other** modules.
And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.
BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.
This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.
---
clang/docs/ReleaseNotes.rst | 2 +
clang/include/clang/AST/DeclBase.h| 10 +
clang/include/clang/AST/ExternalASTMerger.h | 3 +-
clang/include/clang/AST/ExternalASTSource.h | 17 +-
.../clang/Sema/MultiplexExternalSemaSource.h | 3 +-
.../include/clang/Serialization/ASTBitCodes.h | 6 +
clang/include/clang/Serialization/ASTReader.h | 32 +-
clang/include/clang/Serialization/ASTWriter.h | 16 +-
clang/lib/AST/DeclBase.cpp| 23 +-
clang/lib/AST/ExternalASTMerger.cpp | 3 +-
clang/lib/AST/ExternalASTSource.cpp | 6 +-
clang/lib/Interpreter/CodeCompletion.cpp | 6 +-
.../lib/Sema/MultiplexExternalSemaSource.cpp | 7 +-
clang/lib/Serialization/ASTReader.cpp | 195 ++---
clang/lib/Serialization/ASTReaderDecl.cpp | 69 +++--
clang/lib/Serialization/ASTReaderInternals.h | 72 -
clang/lib/Serialization/ASTWriter.cpp | 273 ++
clang/lib/Serialization/ASTWriterDecl.cpp | 13 +-
.../basic.scope/basic.scope.namespace/p2.cpp | 4 +-
.../test/CXX/module/basic/basic.link/p2.cppm | 3 +-
clang/test/CXX/module/module.import/p2.cpp| 10 +-
clang/test/CXX/module/module.interface/p7.cpp | 10 +-
clang/test/CXX/module/module.reach/p5.cpp | 3 +-
.../Reachability-template-default-arg.cpp | 3 +-
clang/test/Modules/cxx20-10-1-ex2.cpp | 3 +-
clang/test/Modules/deduction-guide3.cppm | 4 +-
.../Modules/module-local-with-templates.cppm | 79 +
clang/test/Modules/pr90154.cppm | 25 ++
clang/unittests/AST/ExternalASTSourceTest.cpp | 3 +-
.../Plugins/ExpressionParser/Clang/ASTUtils.h | 10 +-
.../ExpressionParser/Clang/ClangASTSource.cpp | 3 +-
.../ExpressionParser/Clang/ClangASTSource.h | 8 +-
.../Clang/ClangExternalASTSourceCallbacks.cpp | 3 +-
.../Clang/ClangExternalASTSourceCallbacks.h | 3 +-
.../AppleObjCRuntime/AppleObjCDeclVendor.cpp | 3 +-
35 files changed, 736 insertions(+), 197 deletions(-)
create mode 100644 clang/test/Modules/module-local-with-templates.cppm
create mode 100644 clang/test/Modules/pr90154.cppm
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9eeb872aa57d79..142ed6e19b0a79 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -316,6 +316,8 @@ C++23 Feature Support
C++20 Feature Support
^
+- Implemented module level lookup for C++20 modules. (#GH90154)
+
Resolutions to C++ Defect Reports
^
diff --git a/clang/include/clang/AST/DeclBase.h
b/clang/include/clang/AST/DeclBase.h
index 77abd8b657a616..8686c2fe95dd6d 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -836,6 +836,10 @@ class alignas(8) Decl {
return isFromASTFile() ? getImportedOwningModule() :
getLocalOwningModule();
}
+ /// G
[Lldb-commits] [lldb] [lldb][test] Fix some 'import-std-module' tests (PR #122358)
Prabhuk wrote: Hi @dzhidzhoev! I am seeing failures in our lldb builders and from the list of commits that went into the build this PR seems to be the likely cause though I am not completely sure. This is the builder link: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/lldb-linux-arm64/b8725815472020390097/overview Logs: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8725815472020390097/+/u/test_lldb/check_lldb/stdout I am working on verifying if our builders pass without your patch from my side. https://github.com/llvm/llvm-project/pull/122358 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [clang-tools-extra] [lldb] [Clang] [NFC] Rename `isAnyPointerType()` and `getPointeeOrArrayElementType()`. (PR #122938)
Sirraide wrote: > A few comment: `getPointerLikeOrArrayElementType` is not used, and I'm rather > concerned by what it does. > Removing pointiness in only some cases seem dangerous, and not super useful... That’s fair, I don’t think it’s crucial to add that or anything. > Renaming `getPointeeOrArrayElementType` to `getPointerOrArrayElementType` > seems wrong. However, if we put an assert in these function that the type is > indeed a pointer or an array, how much code break? I suspect not much, and we > could fix the caller. ie this function is too magic/does too much. Ah, I think you’re confusing two functions there: `getPointeeOrArrayElementType()` is being renamed to `getPointerOrObjCPointerOrArrayElementType()`, not `getPointerOrArrayElementType()`. https://github.com/llvm/llvm-project/pull/122938 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add APIs enabling OperatingSystem plugins to update ThreadPlanStack (PR #122966)
https://github.com/felipepiovezan created
https://github.com/llvm/llvm-project/pull/122966
At the end of Process::UpdateThreadListIfNeeded, we see this comment:
```
// Now update the plan stack map.
// If we do have an OS plugin, any absent real threads in the
// m_thread_list have already been removed from the ThreadPlanStackMap.
// So any remaining threads are OS Plugin threads, and those we want to
// preserve in case they show up again.
m_thread_plans.Update(m_thread_list, clear_unused_threads);
```
In other words, if a OS plugin maps a real thread to a plugin thread, the
plugin is expected to remove the thread plan of the real thread from
`m_thread_plans`.
However, it is impossible to do so today: the APIs are simply not there. In
fact, plugins don't even have access to `m_thread_plans`. This is not a problem
for plugins who "report all threads", since LLDB will then clean up plans for
any threads that are not present in the new list of threads (mapped real
threads won't be in the new list). For plugins that do _not_ report all
threads, this is a problem.
There are two pieces missing here:
A) The `OperatingSystem::UpdateThreadList` function needs access to
m_thread_plans.
B) ThreadPlanStack needs to expose the TIDs it currently knows about, since its
methods (like Find, Erase) are all TID-based.
This commit provides these pieces so that future commits (and plugins) may make
use of them.
Point A is currently addressed by passing m_thread_plans as a function argument
to OperatingSystem::UpdateThreadList, however it would have been made public
through an accessor method in Process.
>From 8dc10cccedc5a1d1e00affa5a6440c0dd88bd619 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Mon, 13 Jan 2025 09:17:07 -0800
Subject: [PATCH] [lldb] Add APIs enabling OperatingSystem plugins to update
ThreadPlanStack
At the end of Process::UpdateThreadListIfNeeded, we see this comment:
```
// Now update the plan stack map.
// If we do have an OS plugin, any absent real threads in the
// m_thread_list have already been removed from the ThreadPlanStackMap.
// So any remaining threads are OS Plugin threads, and those we want to
// preserve in case they show up again.
m_thread_plans.Update(m_thread_list, clear_unused_threads);
```
In other words, if a OS plugin maps a real thread to a plugin thread,
the plugin is expected to remove the thread plan of the real thread from
`m_thread_plans`.
However, it is impossible to do so today: the APIs are simply not there.
In fact, plugins don't even have access to `m_thread_plans`. This is not
a problem for plugins who "report all threads", since LLDB will then
clean up plans for any threads that are not present in the new list of
threads (mapped real threads won't be in the new list). For plugins that
do _not_ report all threads, this is a problem.
There are two pieces missing here:
A) The `OperatingSystem::UpdateThreadList` function needs access to
m_thread_plans.
B) ThreadPlanStack needs to expose the TIDs it currently knows about,
since its methods (like Find, Erase) are all TID-based.
This commit provides these pieces so that future commits (and plugins)
may make use of them.
Point A is currently addressed by passing m_thread_plans as a function
argument to OperatingSystem::UpdateThreadList, however it would have
been made public through an accessor method in Process.
---
lldb/include/lldb/Target/OperatingSystem.h| 4 +++-
lldb/include/lldb/Target/ThreadPlanStack.h| 7 +++
.../OperatingSystem/Python/OperatingSystemPython.cpp | 3 ++-
.../OperatingSystem/Python/OperatingSystemPython.h| 8 +---
lldb/source/Target/Process.cpp| 3 ++-
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/lldb/include/lldb/Target/OperatingSystem.h
b/lldb/include/lldb/Target/OperatingSystem.h
index ceeddceb0f2c12..d02bd3fb017388 100644
--- a/lldb/include/lldb/Target/OperatingSystem.h
+++ b/lldb/include/lldb/Target/OperatingSystem.h
@@ -14,6 +14,7 @@
#include "lldb/lldb-private.h"
namespace lldb_private {
+class ThreadPlanStackMap;
/// \class OperatingSystem OperatingSystem.h "lldb/Target/OperatingSystem.h"
/// A plug-in interface definition class for halted OS helpers.
@@ -45,7 +46,8 @@ class OperatingSystem : public PluginInterface {
// Plug-in Methods
virtual bool UpdateThreadList(ThreadList &old_thread_list,
ThreadList &real_thread_list,
-ThreadList &new_thread_list) = 0;
+ThreadList &new_thread_list,
+ThreadPlanStackMap &plan_stack_map) = 0;
virtual void ThreadWasSelected(Thread *thread) = 0;
diff --git a/lldb/include/lldb/Target/ThreadPlanStack.h
b/lldb/include/lldb/Target/ThreadPlanStack.h
index e0f8104de9a4d1..da4dac5595d62d 100644
--- a/lldb/includ
[Lldb-commits] [lldb] [lldb] Add APIs enabling OperatingSystem plugins to update ThreadPlanStack (PR #122966)
https://github.com/felipepiovezan updated
https://github.com/llvm/llvm-project/pull/122966
>From c8e7e22ada455c1097e7a3499c3cc152a6bef0fa Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan
Date: Mon, 13 Jan 2025 09:17:07 -0800
Subject: [PATCH] [lldb] Add APIs enabling OperatingSystem plugins to update
ThreadPlanStack
At the end of Process::UpdateThreadListIfNeeded, we see this comment:
```
// Now update the plan stack map.
// If we do have an OS plugin, any absent real threads in the
// m_thread_list have already been removed from the ThreadPlanStackMap.
// So any remaining threads are OS Plugin threads, and those we want to
// preserve in case they show up again.
m_thread_plans.Update(m_thread_list, clear_unused_threads);
```
In other words, if a OS plugin maps a real thread to a plugin thread,
the plugin is expected to remove the thread plan of the real thread from
`m_thread_plans`.
However, it is impossible to do so today: the APIs are simply not there.
In fact, plugins don't even have access to `m_thread_plans`. This is not
a problem for plugins who "report all threads", since LLDB will then
clean up plans for any threads that are not present in the new list of
threads (mapped real threads won't be in the new list). For plugins that
do _not_ report all threads, this is a problem.
There are two pieces missing here:
A) The `OperatingSystem::UpdateThreadList` function needs access to
m_thread_plans.
B) ThreadPlanStack needs to expose the TIDs it currently knows about,
since its methods (like Find, Erase) are all TID-based.
This commit provides these pieces so that future commits (and plugins)
may make use of them.
Point A is currently addressed by passing m_thread_plans as a function
argument to OperatingSystem::UpdateThreadList, however it would have
been possible to make it public through an accessor method in Process.
---
lldb/include/lldb/Target/OperatingSystem.h| 4 +++-
lldb/include/lldb/Target/ThreadPlanStack.h| 7 +++
.../OperatingSystem/Python/OperatingSystemPython.cpp | 3 ++-
.../OperatingSystem/Python/OperatingSystemPython.h| 8 +---
lldb/source/Target/Process.cpp| 3 ++-
5 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/lldb/include/lldb/Target/OperatingSystem.h
b/lldb/include/lldb/Target/OperatingSystem.h
index ceeddceb0f2c12..d02bd3fb017388 100644
--- a/lldb/include/lldb/Target/OperatingSystem.h
+++ b/lldb/include/lldb/Target/OperatingSystem.h
@@ -14,6 +14,7 @@
#include "lldb/lldb-private.h"
namespace lldb_private {
+class ThreadPlanStackMap;
/// \class OperatingSystem OperatingSystem.h "lldb/Target/OperatingSystem.h"
/// A plug-in interface definition class for halted OS helpers.
@@ -45,7 +46,8 @@ class OperatingSystem : public PluginInterface {
// Plug-in Methods
virtual bool UpdateThreadList(ThreadList &old_thread_list,
ThreadList &real_thread_list,
-ThreadList &new_thread_list) = 0;
+ThreadList &new_thread_list,
+ThreadPlanStackMap &plan_stack_map) = 0;
virtual void ThreadWasSelected(Thread *thread) = 0;
diff --git a/lldb/include/lldb/Target/ThreadPlanStack.h
b/lldb/include/lldb/Target/ThreadPlanStack.h
index e0f8104de9a4d1..da4dac5595d62d 100644
--- a/lldb/include/lldb/Target/ThreadPlanStack.h
+++ b/lldb/include/lldb/Target/ThreadPlanStack.h
@@ -179,6 +179,13 @@ class ThreadPlanStackMap {
bool PrunePlansForTID(lldb::tid_t tid);
+ std::vector GetKnownTIDs() const {
+std::vector TIDs;
+for (auto &plan_stack : m_plans_up_container)
+ TIDs.push_back(plan_stack->GetTID());
+return TIDs;
+ }
+
private:
Process &m_process;
mutable std::recursive_mutex m_stack_map_mutex;
diff --git
a/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
b/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
index 3848a2b1deb97f..85ff005f7eac8a 100644
--- a/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
+++ b/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.cpp
@@ -163,7 +163,8 @@ DynamicRegisterInfo
*OperatingSystemPython::GetDynamicRegisterInfo() {
bool OperatingSystemPython::UpdateThreadList(ThreadList &old_thread_list,
ThreadList &core_thread_list,
- ThreadList &new_thread_list) {
+ ThreadList &new_thread_list,
+ ThreadPlanStackMap &) {
if (!m_interpreter || !m_operating_system_interface_sp)
return false;
diff --git a/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h
b/lldb/source/Plugins/OperatingSystem/Python/OperatingSystemPython.h
index 90973acde3ebfd..e9782ae8b2c59b 100644
---
[Lldb-commits] [lldb] [lldb] Add APIs enabling OperatingSystem plugins to update ThreadPlanStack (PR #122966)
https://github.com/felipepiovezan edited https://github.com/llvm/llvm-project/pull/122966 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
ldionne wrote: @kstoimenov @vitalybuka Could you folks show us how the sanitizer builds you run are different from the ones we already run in our CI pipeline? It would be important to align both since we often run into issues with your post-commit CI jobs failing but our pre-commit CI not catching it. https://github.com/llvm/llvm-project/pull/115380 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libc++] Stop copying headers to the build directory (PR #115380)
vitalybuka wrote:
> @kstoimenov @vitalybuka Could you folks show us how the sanitizer builds you
> run are different from the ones we already run in our CI pipeline? It would
> be important to align both since we often run into issues with your
> post-commit CI jobs failing but our pre-commit CI not catching it.
We have many of them:
1. This one is from
https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh,
which is strange build for `cmake -DCOMPILER_RT_ENABLE_INTERNAL_SYMBOLIZER=ON`
This build is strange, but I don't remember it breaks libc++ before. I don't
think it worse having it on pre-submit.
2. Then a bunch of
https://lab.llvm.org/buildbot/#/builders/sanitizer-{x86_64,aarch64}-linux-bootstrap-{asan,msan,ubsan,hwasan}/
```
/usr/bin/cmake -DLLVM_APPEND_VC_REV=OFF -GNinja -DCMAKE_BUILD_TYPE=Release
-DLLVM_CCACHE_BUILD=ON -DLLVM_USE_LINKER=lld -DLLVM_ENABLE_ASSERTIONS=ON
-DCMAKE_C_COMPILER=/home/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build0/bin/clang
-DCMAKE_CXX_COMPILER=/home/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build0/bin/clang++
-DLIBCXXABI_USE_LLVM_UNWINDER=OFF
-DCMAKE_INSTALL_PREFIX=/home/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/libcxx_install_ubsan
'-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi'
-DLIBCXX_TEST_PARAMS=long_tests=False -DLIBCXX_INCLUDE_BENCHMARKS=OFF
-DLLVM_USE_SANITIZER=Undefined '-DCMAKE_C_FLAGS=-fsanitize=undefined
-fno-sanitize-recover=all -fno-sanitize=vptr'
'-DCMAKE_CXX_FLAGS=-fsanitize=undefined -fno-sanitize-recover=all
-fno-sanitize=vptr'
/home/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/llvm/../runtimes--
```
These must be very close to what libc++ have in CI.
Main diff is that we repeat sanitizers in -DCMAKE_CXX_FLAGS.
The most important part of this build is instrumented libc++ used for 2nd
stage clang build. But it's very slow. I don't expect we can afford this on
pre-commit CI.
3. For some sanitizers there is nested libcxx build
https://github.com/search?q=repo%3Allvm%2Fllvm-project%20add_custom_libcxx&type=code
correctly configured "check-compiler-rt" should cover them. I suspect you don't
have these on pre-commit, maybe it worse having them.
https://github.com/llvm/llvm-project/pull/115380
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
cmtice wrote: (Also, I will split the Lexer into a separate PR) https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add DIL code for handling plain variable names. (PR #120971)
cmtice wrote: I've addressed a lot of the review comments, but I'm still working on some. https://github.com/llvm/llvm-project/pull/120971 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,18 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
- /// \return \c true if any declarations might have been found, \c false if
- /// we definitely have no declarations with tbis name.
+ /// \param DC since the same namespace can appear in multiple module units.
+ /// \param Name the name of the declarations to find.
+ /// \param NamedModule find declarations visible to the given module
+ /// \c NamedModule . This may be different from owning module of \c DC since
+ /// there are declarations (e.g., namespace declaration) can appear in
+ /// multiple modules. \return \c true if any declarations might have been
+ /// found, \c false if we definitely have no declarations with tbis name.
ChuanqiXu9 wrote:
Done, thanks.
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/122887
>From 0e49792900783f442da68b89fc3b4b3e013d18d3 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 26 Dec 2024 16:00:51 +0800
Subject: [PATCH] [C++20] [Modules] Support module level lookup
Close https://github.com/llvm/llvm-project/issues/90154
This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.
Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.
Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.
In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as the key.
And refactored `DeclContext::lookup()` method to take the module
information. So that a lookup in a DeclContext won't load declarations
that are local to **other** modules.
And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.
BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.
This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.
---
clang/docs/ReleaseNotes.rst | 2 +
clang/include/clang/AST/DeclBase.h| 10 +
clang/include/clang/AST/ExternalASTMerger.h | 3 +-
clang/include/clang/AST/ExternalASTSource.h | 17 +-
.../clang/Sema/MultiplexExternalSemaSource.h | 3 +-
.../include/clang/Serialization/ASTBitCodes.h | 6 +
clang/include/clang/Serialization/ASTReader.h | 32 +-
clang/include/clang/Serialization/ASTWriter.h | 16 +-
clang/lib/AST/DeclBase.cpp| 23 +-
clang/lib/AST/ExternalASTMerger.cpp | 3 +-
clang/lib/AST/ExternalASTSource.cpp | 6 +-
clang/lib/Interpreter/CodeCompletion.cpp | 6 +-
.../lib/Sema/MultiplexExternalSemaSource.cpp | 7 +-
clang/lib/Serialization/ASTReader.cpp | 195 ++---
clang/lib/Serialization/ASTReaderDecl.cpp | 69 +++--
clang/lib/Serialization/ASTReaderInternals.h | 72 -
clang/lib/Serialization/ASTWriter.cpp | 273 ++
clang/lib/Serialization/ASTWriterDecl.cpp | 13 +-
.../basic.scope/basic.scope.namespace/p2.cpp | 4 +-
.../test/CXX/module/basic/basic.link/p2.cppm | 3 +-
clang/test/CXX/module/module.import/p2.cpp| 10 +-
clang/test/CXX/module/module.interface/p7.cpp | 10 +-
clang/test/CXX/module/module.reach/p5.cpp | 3 +-
.../Reachability-template-default-arg.cpp | 3 +-
clang/test/Modules/cxx20-10-1-ex2.cpp | 3 +-
clang/test/Modules/deduction-guide3.cppm | 4 +-
.../Modules/module-local-with-templates.cppm | 79 +
clang/test/Modules/pr90154.cppm | 25 ++
clang/unittests/AST/ExternalASTSourceTest.cpp | 3 +-
.../Plugins/ExpressionParser/Clang/ASTUtils.h | 10 +-
.../ExpressionParser/Clang/ClangASTSource.cpp | 3 +-
.../ExpressionParser/Clang/ClangASTSource.h | 8 +-
.../Clang/ClangExternalASTSourceCallbacks.cpp | 3 +-
.../Clang/ClangExternalASTSourceCallbacks.h | 3 +-
.../AppleObjCRuntime/AppleObjCDeclVendor.cpp | 3 +-
35 files changed, 736 insertions(+), 197 deletions(-)
create mode 100644 clang/test/Modules/module-local-with-templates.cppm
create mode 100644 clang/test/Modules/pr90154.cppm
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 9eeb872aa57d79..142ed6e19b0a79 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -316,6 +316,8 @@ C++23 Feature Support
C++20 Feature Support
^
+- Implemented module level lookup for C++20 modules. (#GH90154)
+
Resolutions to C++ Defect Reports
^
diff --git a/clang/include/clang/AST/DeclBase.h
b/clang/include/clang/AST/DeclBase.h
index 77abd8b657a616..8686c2fe95dd6d 100644
--- a/clang/include/clang/AST/DeclBase.h
+++ b/clang/include/clang/AST/DeclBase.h
@@ -836,6 +836,10 @@ class alignas(8) Decl {
return isFromASTFile() ? getImportedOwningModule() :
getLocalOwningModule();
}
+ /// G
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
@@ -145,12 +146,18 @@ class ExternalASTSource : public
RefCountedBase {
/// Find all declarations with the given name in the given context,
/// and add them to the context by calling SetExternalVisibleDeclsForName
/// or SetNoExternalVisibleDeclsForName.
- /// \return \c true if any declarations might have been found, \c false if
- /// we definitely have no declarations with tbis name.
+ /// \param DC since the same namespace can appear in multiple module units.
ChuanqiXu9 wrote:
Yes, done.
https://github.com/llvm/llvm-project/pull/122887
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 7201cae - [C++20] [Modules] Support module level lookup (#122887)
Author: Chuanqi Xu Date: 2025-01-15T15:15:35+08:00 New Revision: 7201cae106260aeb3e97d5291ff30f05076a URL: https://github.com/llvm/llvm-project/commit/7201cae106260aeb3e97d5291ff30f05076a DIFF: https://github.com/llvm/llvm-project/commit/7201cae106260aeb3e97d5291ff30f05076a.diff LOG: [C++20] [Modules] Support module level lookup (#122887) Close https://github.com/llvm/llvm-project/issues/90154 This patch is also an optimization to the lookup process to utilize the information provided by `export` keyword. Previously, in the lookup process, the `export` keyword only takes part in the check part, it doesn't get involved in the lookup process. That said, previously, in a name lookup for 'name', we would load all of declarations with the name 'name' and check if these declarations are valid or not. It works well. But it is inefficient since it may load declarations that may not be wanted. Note that this patch actually did a trick in the lookup process instead of bring module information to DeclarationName or considering module information when deciding if two declarations are the same. So it may not be a surprise to me if there are missing cases. But it is not a regression. It should be already the case. Issue reports are welcomed. In this patch, I tried to split the big lookup table into a lookup table as before and a module local lookup table, which takes a combination of the ID of the DeclContext and hash value of the primary module name as the key. And refactored `DeclContext::lookup()` method to take the module information. So that a lookup in a DeclContext won't load declarations that are local to **other** modules. And also I think it is already beneficial to split the big lookup table since it may reduce the conflicts during lookups in the hash table. BTW, this patch introduced a **regression** for a reachability rule in C++20 but it was false-negative. See 'clang/test/CXX/module/module.interface/p7.cpp' for details. This patch is not expected to introduce any other regressions for non-c++20-modules users since the module local lookup table should be empty for them. --- On the API side, this patch unfortunately add a maybe-confusing argument `Module *NamedModule` to `ExternalASTSource::FindExternalVisibleDeclsByName()`. People may think we can get the information from the first argument `const DeclContext *DC`. But sadly there are declarations (e.g., namespace) can appear in multiple different modules as a single declaration. So we have to add additional information to indicate this. Added: clang/test/Modules/module-local-with-templates.cppm clang/test/Modules/pr90154.cppm Modified: clang/docs/ReleaseNotes.rst clang/include/clang/AST/DeclBase.h clang/include/clang/AST/ExternalASTMerger.h clang/include/clang/AST/ExternalASTSource.h clang/include/clang/Sema/MultiplexExternalSemaSource.h clang/include/clang/Serialization/ASTBitCodes.h clang/include/clang/Serialization/ASTReader.h clang/include/clang/Serialization/ASTWriter.h clang/lib/AST/DeclBase.cpp clang/lib/AST/ExternalASTMerger.cpp clang/lib/AST/ExternalASTSource.cpp clang/lib/Interpreter/CodeCompletion.cpp clang/lib/Sema/MultiplexExternalSemaSource.cpp clang/lib/Serialization/ASTReader.cpp clang/lib/Serialization/ASTReaderDecl.cpp clang/lib/Serialization/ASTReaderInternals.h clang/lib/Serialization/ASTWriter.cpp clang/lib/Serialization/ASTWriterDecl.cpp clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp clang/test/CXX/module/basic/basic.link/p2.cppm clang/test/CXX/module/module.import/p2.cpp clang/test/CXX/module/module.interface/p7.cpp clang/test/CXX/module/module.reach/p5.cpp clang/test/Modules/Reachability-template-default-arg.cpp clang/test/Modules/cxx20-10-1-ex2.cpp clang/test/Modules/deduction-guide3.cppm clang/unittests/AST/ExternalASTSourceTest.cpp lldb/source/Plugins/ExpressionParser/Clang/ASTUtils.h lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.h lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.cpp lldb/source/Plugins/ExpressionParser/Clang/ClangExternalASTSourceCallbacks.h lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp Removed: diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst index 6ac91f43e66d8b..c6bc95594f6133 100644 --- a/clang/docs/ReleaseNotes.rst +++ b/clang/docs/ReleaseNotes.rst @@ -316,6 +316,8 @@ C++23 Feature Support C++20 Feature Support ^ +- Implemented module level lookup for C++20 modules. (#GH90154) + Resolutions to C++ Defect Reports ^ diff --git a/clang/include/clang/AST/DeclBase.h b/clang/include/clang/AST/DeclBase.h index 71ab9178509b
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
https://github.com/ChuanqiXu9 closed https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [lldb] [C++20] [Modules] Support module level lookup (PR #122887)
ChuanqiXu9 wrote: Now CI passes. I want to land this in 20.x and give it some baking times so that we can find issues in it if any. Post commit review comments are welcomed as always. https://github.com/llvm/llvm-project/pull/122887 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 5dcf5cc - [lldb] Remove unfiltered stop reason propagation from StopInfoMachException (#122817)
Author: Felipe de Azevedo Piovezan
Date: 2025-01-14T11:25:58-08:00
New Revision: 5dcf5cc0e0b462be99d1ae3d993ec11b039097b8
URL:
https://github.com/llvm/llvm-project/commit/5dcf5cc0e0b462be99d1ae3d993ec11b039097b8
DIFF:
https://github.com/llvm/llvm-project/commit/5dcf5cc0e0b462be99d1ae3d993ec11b039097b8.diff
LOG: [lldb] Remove unfiltered stop reason propagation from
StopInfoMachException (#122817)
In the presence of OS plugins, StopInfoMachException currently
propagates breakpoint stop reasons even if those breakpoints were not
intended for a specific thread, effectively removing our ability to set
thread-specific breakpoints.
This was originally added in [1], but the motivation provided in the
comment does not seem strong enough to remove the ability to set
thread-specific breakpoints. The only way to break thread specific
breakpoints would be if a user set such a breakpoint and _then_ loaded
an OS plugin, a scenario which we would likely not want to support.
[1]:
https://github.com/swiftlang/llvm-project/commit/ab745c2ad865c07f3905482fd071ef36c024713a#diff-8ec6e41b1dffa7ac4b5841aae24d66442ef7ebc62c8618f89354d84594f91050R501
Added:
Modified:
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
lldb/test/API/functionalities/plugins/python_os_plugin/main.c
Removed:
diff --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index d08e99f4844de3..698ba0f0f720f6 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -780,13 +780,8 @@ StopInfoSP
StopInfoMachException::CreateStopReasonWithMachException(
// but if it is for another thread, we can just report no reason. We
// don't need to worry about stepping over the breakpoint here, that
// will be taken care of when the thread resumes and notices that
-// there's a breakpoint under the pc. If we have an operating system
-// plug-in, we might have set a thread specific breakpoint using the
-// operating system thread ID, so we can't make any assumptions about
-// the thread ID so we must always report the breakpoint regardless
-// of the thread.
-if (bp_site_sp->ValidForThisThread(thread) ||
-thread.GetProcess()->GetOperatingSystem() != nullptr)
+// there's a breakpoint under the pc.
+if (bp_site_sp->ValidForThisThread(thread))
return StopInfo::CreateStopReasonWithBreakpointSiteID(
thread, bp_site_sp->GetID());
else if (is_trace_if_actual_breakpoint_missing)
diff --git
a/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
b/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
index 479c94c2315407..3ad7539018d5d8 100644
---
a/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
+++
b/lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
@@ -219,3 +219,12 @@ def run_python_os_step(self):
6,
"Make sure we stepped from line 5 to line 6 in main.c",
)
+
+thread_bp_number = lldbutil.run_break_set_by_source_regexp(
+self, "Set tid-specific breakpoint here", num_expected_locations=1
+)
+breakpoint = target.FindBreakpointByID(thread_bp_number)
+# This breakpoint should not be hit.
+breakpoint.SetThreadID(123)
+process.Continue()
+self.assertState(process.GetState(), lldb.eStateExited)
diff --git a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
index faa6dd58ecd62b..deb80027c5e6c2 100644
--- a/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
+++ b/lldb/test/API/functionalities/plugins/python_os_plugin/main.c
@@ -3,5 +3,7 @@
int main (int argc, char const *argv[], char const *envp[])
{
puts("stop here"); // Set breakpoint here
+puts("hello");
+puts("Set tid-specific breakpoint here");
return 0;
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove unfiltered stop reason propagation from StopInfoMachException (PR #122817)
https://github.com/felipepiovezan closed https://github.com/llvm/llvm-project/pull/122817 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Make the thread list for SBSaveCoreOptions iterable (PR #122541)
https://github.com/Jlalond updated
https://github.com/llvm/llvm-project/pull/122541
>From 5a756db04b1e5124b99fa44c162439fbf8385aee Mon Sep 17 00:00:00 2001
From: Jacob Lalonde
Date: Fri, 10 Jan 2025 14:26:10 -0800
Subject: [PATCH 1/7] Make the thread list for SBSaveCoreOptions iterable
---
lldb/include/lldb/API/SBSaveCoreOptions.h | 15 +++
lldb/include/lldb/Symbol/SaveCoreOptions.h| 8 +++-
lldb/source/API/SBSaveCoreOptions.cpp | 13 ++
lldb/source/Symbol/SaveCoreOptions.cpp| 34 +++---
.../TestSBSaveCoreOptions.py | 45 +--
.../sbsavecoreoptions/basic_minidump.yaml | 10 +
6 files changed, 114 insertions(+), 11 deletions(-)
diff --git a/lldb/include/lldb/API/SBSaveCoreOptions.h
b/lldb/include/lldb/API/SBSaveCoreOptions.h
index 74aa2fe5bd5f92..d480b6272749e6 100644
--- a/lldb/include/lldb/API/SBSaveCoreOptions.h
+++ b/lldb/include/lldb/API/SBSaveCoreOptions.h
@@ -111,6 +111,21 @@ class LLDB_API SBSaveCoreOptions {
/// style specific regions.
SBError AddMemoryRegionToSave(const SBMemoryRegionInfo ®ion);
+ /// Get the number of Threads to be saved
+ ///
+ /// \returns
+ /// The count of Threads to be saved.
+ uint32_t GetNumThreads() const;
+
+ /// Get the Thread at the specified index.
+ ///
+ /// \param [in] idx
+ /// The index of the thread to return.
+ /// \returns
+ /// The thread at the specified index, or an empty thread if the index is
+ /// greater than or equal to the number of threads.
+ lldb::SBThread GetThreadAtIndex(uint32_t idx) const;
+
/// Reset all options.
void Clear();
diff --git a/lldb/include/lldb/Symbol/SaveCoreOptions.h
b/lldb/include/lldb/Symbol/SaveCoreOptions.h
index d90d08026016dc..b33e02b2d72922 100644
--- a/lldb/include/lldb/Symbol/SaveCoreOptions.h
+++ b/lldb/include/lldb/Symbol/SaveCoreOptions.h
@@ -13,7 +13,6 @@
#include "lldb/Utility/RangeMap.h"
#include
-#include
#include
#include
@@ -47,6 +46,9 @@ class SaveCoreOptions {
void AddMemoryRegionToSave(const lldb_private::MemoryRegionInfo ®ion);
+ std::optional GetThreadAtIndex(uint32_t idx) const;
+ uint32_t GetNumThreads() const;
+
void Clear();
private:
@@ -56,8 +58,10 @@ class SaveCoreOptions {
std::optional m_file;
std::optional m_style;
lldb::ProcessSP m_process_sp;
- std::unordered_set m_threads_to_save;
+ std::unordered_map m_threads_to_save;
MemoryRanges m_regions_to_save;
+
+ std::vector m_thread_indexes;
};
} // namespace lldb_private
diff --git a/lldb/source/API/SBSaveCoreOptions.cpp
b/lldb/source/API/SBSaveCoreOptions.cpp
index c79b57fa62c2be..6e50145add822e 100644
--- a/lldb/source/API/SBSaveCoreOptions.cpp
+++ b/lldb/source/API/SBSaveCoreOptions.cpp
@@ -100,6 +100,19 @@ SBSaveCoreOptions::AddMemoryRegionToSave(const
SBMemoryRegionInfo ®ion) {
return SBError();
}
+uint32_t lldb::SBSaveCoreOptions::GetNumThreads() const {
+ LLDB_INSTRUMENT_VA(this);
+ return m_opaque_up->GetNumThreads();
+}
+
+SBThread SBSaveCoreOptions::GetThreadAtIndex(uint32_t idx) const {
+ LLDB_INSTRUMENT_VA(this, idx);
+ std::optional thread_sp = m_opaque_up->GetThreadAtIndex(idx);
+ if (thread_sp)
+return SBThread(thread_sp.value());
+ return SBThread();
+}
+
void SBSaveCoreOptions::Clear() {
LLDB_INSTRUMENT_VA(this);
m_opaque_up->Clear();
diff --git a/lldb/source/Symbol/SaveCoreOptions.cpp
b/lldb/source/Symbol/SaveCoreOptions.cpp
index 8d9aadece2152d..84c4a76f09453e 100644
--- a/lldb/source/Symbol/SaveCoreOptions.cpp
+++ b/lldb/source/Symbol/SaveCoreOptions.cpp
@@ -87,12 +87,33 @@ Status SaveCoreOptions::AddThread(lldb::ThreadSP thread_sp)
{
m_process_sp = thread_sp->GetProcess();
}
- m_threads_to_save.insert(thread_sp->GetID());
+ m_threads_to_save.insert({thread_sp->GetID(), thread_sp});
+ m_thread_indexes.push_back(thread_sp->GetID());
return error;
}
bool SaveCoreOptions::RemoveThread(lldb::ThreadSP thread_sp) {
- return thread_sp && m_threads_to_save.erase(thread_sp->GetID()) > 0;
+ if (!thread_sp)
+return false;
+ if (m_threads_to_save.erase(thread_sp->GetID()) == 0)
+return false;
+
+ auto it = std::find(m_thread_indexes.begin(), m_thread_indexes.end(),
+ thread_sp->GetID());
+ m_thread_indexes.erase(it);
+ return true;
+}
+
+uint32_t SaveCoreOptions::GetNumThreads() const {
+ return m_threads_to_save.size();
+}
+
+std::optional
+SaveCoreOptions::GetThreadAtIndex(uint32_t idx) const {
+ if (idx >= m_thread_indexes.size())
+return std::nullopt;
+ lldb::tid_t tid = m_thread_indexes[idx];
+ return m_threads_to_save.find(tid)->second;
}
bool SaveCoreOptions::ShouldThreadBeSaved(lldb::tid_t tid) const {
@@ -115,8 +136,8 @@ const MemoryRanges
&SaveCoreOptions::GetCoreFileMemoryRanges() const {
return m_regions_to_save;
}
-Status SaveCoreOptions::EnsureValidConfiguration(
-lldb::ProcessSP process_sp) const {
+Status
+SaveCoreOptions::EnsureValidConfiguration(lldb::
[Lldb-commits] [lldb] [LLDB] Make the thread list for SBSaveCoreOptions iterable (PR #122541)
@@ -115,8 +115,21 @@ const MemoryRanges
&SaveCoreOptions::GetCoreFileMemoryRanges() const {
return m_regions_to_save;
}
-Status SaveCoreOptions::EnsureValidConfiguration(
-lldb::ProcessSP process_sp) const {
+lldb::ThreadCollectionSP SaveCoreOptions::GetThreadsToSave() const {
Jlalond wrote:
The SBThreadCollection's protected constructor only supports an
ThreadCollection_SP. So without changing that I won't be able to only pass by
value.
https://github.com/llvm/llvm-project/pull/122541
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add OpenBSD signals (PR #123005)
https://github.com/brad0 updated
https://github.com/llvm/llvm-project/pull/123005
>From 25e59d64f085df535c62676ae8ec00a778def8f9 Mon Sep 17 00:00:00 2001
From: Brad Smith
Date: Tue, 14 Jan 2025 22:25:00 -0500
Subject: [PATCH] [lldb] Add OpenBSD signals
Signals 1-32 are matching the default UNIX platform.
There are platform specific ones above 32.
---
.../Plugins/Process/Utility/CMakeLists.txt| 1 +
.../Process/Utility/OpenBSDSignals.cpp| 69 +++
.../Plugins/Process/Utility/OpenBSDSignals.h | 27
lldb/source/Target/UnixSignals.cpp| 4 +-
4 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 lldb/source/Plugins/Process/Utility/OpenBSDSignals.cpp
create mode 100644 lldb/source/Plugins/Process/Utility/OpenBSDSignals.h
diff --git a/lldb/source/Plugins/Process/Utility/CMakeLists.txt
b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
index 0e1a5069d4409e..f269f5d7d4d745 100644
--- a/lldb/source/Plugins/Process/Utility/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
@@ -15,6 +15,7 @@ add_lldb_library(lldbPluginProcessUtility
NativeRegisterContextDBReg_x86.cpp
NativeRegisterContextRegisterInfo.cpp
NetBSDSignals.cpp
+ OpenBSDSignals.cpp
RegisterContext_x86.cpp
RegisterContextDarwin_arm.cpp
RegisterContextDarwin_arm64.cpp
diff --git a/lldb/source/Plugins/Process/Utility/OpenBSDSignals.cpp
b/lldb/source/Plugins/Process/Utility/OpenBSDSignals.cpp
new file mode 100644
index 00..48263235126c0a
--- /dev/null
+++ b/lldb/source/Plugins/Process/Utility/OpenBSDSignals.cpp
@@ -0,0 +1,69 @@
+//===-- OpenBSDSignals.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "OpenBSDSignals.h"
+
+#ifdef __OpenBSD__
+#include
+
+#define ADD_SIGCODE(signal_name, signal_value, code_name, code_value, ...)
\
+ static_assert(signal_name == signal_value,
\
+"Value mismatch for signal number " #signal_name);
\
+ static_assert(code_name == code_value,
\
+"Value mismatch for signal code " #code_name);
\
+ AddSignalCode(signal_value, code_value, __VA_ARGS__)
+#else
+#define ADD_SIGCODE(signal_name, signal_value, code_name, code_value, ...)
\
+ AddSignalCode(signal_value, code_value, __VA_ARGS__)
+#endif /* ifdef __OpenBSD */
+
+using namespace lldb_private;
+
+OpenBSDSignals::OpenBSDSignals() : UnixSignals() { Reset(); }
+
+void OpenBSDSignals::Reset() {
+ UnixSignals::Reset();
+
+ // clang-format off
+ // SIGILL
+ ADD_SIGCODE(SIGILL, 4, ILL_ILLOPC, 1, "illegal opcode");
+ ADD_SIGCODE(SIGILL, 4, ILL_ILLOPN, 2, "illegal operand");
+ ADD_SIGCODE(SIGILL, 4, ILL_ILLADR, 3, "illegal addressing mode");
+ ADD_SIGCODE(SIGILL, 4, ILL_ILLTRP, 4, "illegal trap");
+ ADD_SIGCODE(SIGILL, 4, ILL_PRVOPC, 5, "privileged opcode");
+ ADD_SIGCODE(SIGILL, 4, ILL_PRVREG, 6, "privileged register");
+ ADD_SIGCODE(SIGILL, 4, ILL_COPROC, 7, "coprocessor error");
+ ADD_SIGCODE(SIGILL, 4, ILL_BADSTK, 8, "internal stack error");
+ ADD_SIGCODE(SIGILL, 4, ILL_BTCFI, 9, "IBT missing on indirect call");
+
+ // SIGFPE
+ ADD_SIGCODE(SIGFPE, 8, FPE_INTDIV, 1, "integer divide by zero");
+ ADD_SIGCODE(SIGFPE, 8, FPE_INTOVF, 2, "integer overflow");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTDIV, 3, "floating point divide by zero");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTOVF, 4, "floating point overflow");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTUND, 5, "floating point underflow");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTRES, 6, "floating point inexact result");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTINV, 7, "invalid floating point operation");
+ ADD_SIGCODE(SIGFPE, 8, FPE_FLTSUB, 8, "subscript out of range");
+
+ // SIGBUS
+ ADD_SIGCODE(SIGBUS, 10, BUS_ADRALN, 1, "invalid address alignment");
+ ADD_SIGCODE(SIGBUS, 10, BUS_ADRERR, 2, "non-existent physical address");
+ ADD_SIGCODE(SIGBUS, 10, BUS_OBJERR, 3, "object specific hardware error");
+
+ // SIGSEGV
+ ADD_SIGCODE(SIGSEGV, 11, SEGV_MAPERR, 1, "address not mapped to object",
+SignalCodePrintOption::Address);
+ ADD_SIGCODE(SIGSEGV, 11, SEGV_ACCERR, 2, "invalid permissions for mapped
object",
+SignalCodePrintOption::Address);
+
+ //SIGNO NAME SUPPRESS STOP NOTIFY DESCRIPTION
+ //= == == ==
+ AddSignal(32, "SIGTHR", false, false, false, "thread library AST");
+ // clang-format on
+}
diff --git a/lldb/source/Plugins/Process/Utility/OpenBSDSignals.h
b/lldb/source/Plugins/Process/Utility/OpenBSDSignals.h
new file mode 100644
inde
[Lldb-commits] [lldb] [lldb] Add OpenBSD signals (PR #123005)
https://github.com/brad0 edited https://github.com/llvm/llvm-project/pull/123005 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c4fb718 - [lldb][NFC] Make the target's SectionLoadList private. (#113278)
Author: Greg Clayton
Date: 2025-01-14T20:12:46-08:00
New Revision: c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb
URL:
https://github.com/llvm/llvm-project/commit/c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb
DIFF:
https://github.com/llvm/llvm-project/commit/c4fb7180cbbe977f1ab1ce945a691550f8fdd1fb.diff
LOG: [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.
Added:
Modified:
lldb/include/lldb/Target/SectionLoadHistory.h
lldb/include/lldb/Target/Target.h
lldb/source/API/SBBreakpoint.cpp
lldb/source/Breakpoint/BreakpointLocationList.cpp
lldb/source/Commands/CommandObjectDisassemble.cpp
lldb/source/Commands/CommandObjectRegister.cpp
lldb/source/Commands/CommandObjectSource.cpp
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Core/Address.cpp
lldb/source/Core/Disassembler.cpp
lldb/source/Core/DumpDataExtractor.cpp
lldb/source/Core/FormatEntity.cpp
lldb/source/Core/Section.cpp
lldb/source/Core/Value.cpp
lldb/source/DataFormatters/CXXFunctionPointer.cpp
lldb/source/Expression/ObjectFileJIT.cpp
lldb/source/Plugins/Architecture/Mips/ArchitectureMips.cpp
lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.cpp
lldb/source/Plugins/DynamicLoader/Static/DynamicLoaderStatic.cpp
lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
lldb/source/Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Plugins/ObjectFile/Placeholder/ObjectFilePlaceholder.cpp
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/source/Plugins/Trace/intel-pt/TraceIntelPTBundleSaver.cpp
lldb/source/Symbol/ObjectFile.cpp
lldb/source/Target/ProcessTrace.cpp
lldb/source/Target/SectionLoadHistory.cpp
lldb/source/Target/Target.cpp
lldb/source/Target/ThreadPlanStepInRange.cpp
lldb/source/Target/ThreadPlanTracer.cpp
Removed:
diff --git a/lldb/include/lldb/Target/SectionLoadHistory.h
b/lldb/include/lldb/Target/SectionLoadHistory.h
index 64bb828d4254a8..4380d6f2cf1219 100644
--- a/lldb/include/lldb/Target/SectionLoadHistory.h
+++ b/lldb/include/lldb/Target/SectionLoadHistory.h
@@ -45,7 +45,7 @@ class SectionLoadHistory {
const lldb::SectionSP §ion_sp);
bool ResolveLoadAddress(uint32_t stop_id, lldb::addr_t load_addr,
- Address &so_addr);
+ Address &so_addr, bool allow_section_end = false);
bool SetSectionLoadAddress(uint32_t stop_id,
const lldb::SectionSP §ion_sp,
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index 0d1943450d622b..f31ac381391b45 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1151,9 +1151,13 @@ class Target : public
std::enable_shared_from_this,
Address &pointer_addr,
bool force_live_memory = false);
- SectionLoadList &GetSectionLoadList() {
-return m_section_load_history.GetCurrentSectionLoadList();
- }
+ bool HasLoadedSections();
+
+ lldb::addr_t GetSectionLoadAddress(const lldb::SectionSP §ion_sp);
+
+ void ClearSectionLoadList();
+
+ void DumpSectionLoadList(Stream &s);
static Target *GetTargetFromContexts(const ExecutionContext *exe_ctx_ptr,
const SymbolContext *sc_ptr);
@@ -1218,7 +1222,8 @@ class Target : public
std::enable_shared_from_this,
bool ResolveFileAddress(lldb::addr_t load_addr, Address &so_addr);
bool ResolveLoadAddress(lldb::addr_t load_addr, Address &so_addr,
- uint32_t stop_id = SectionLoadHistory::eStopIDNow);
+ uint32_t stop_id = SectionLoadHistory::eStopIDNow,
+ bool allow_section_end = false);
bool SetSectionLoadAddress(const lldb::SectionSP §ion,
lldb::addr_t load_addr,
@@ -1666,6 +1671,10 @@ class Target : public
std::enable_shared_from_this,
Target(const Target &) = delete;
const Target &operator=(const Target &) = delete;
+
+ SectionLoadList &GetSectionLoadList() {
+return m_section_load_histor
[Lldb-commits] [lldb] [lldb][NFC] Make the target's SectionLoadList private. (PR #113278)
https://github.com/clayborg closed https://github.com/llvm/llvm-project/pull/113278 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
