Feature/merge upstream 20210416 #46
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… serialized diagnostics After https://reviews.llvm.org/D90484 libclang is unable to read a serialized diagnostic file which contains a diagnostic which came from a file with an empty filename. The reason being is that the serialized diagnostic reader is creating a virtual file for the "" filename, which now fails after the changes in https://reviews.llvm.org/D90484. This patch restores the previous behavior in getVirtualFileRef by allowing it to construct a file entry ref with an empty name by pretending its name is "." so that the directory entry can be created. Differential Revision: https://reviews.llvm.org/D100428
An empty NAME= should mean that there is no C binding, not the binding that would result from BIND(C) without a NAME=. See 18.10.2p2. Differential Revision: https://reviews.llvm.org/D100494
SROA shifts TBAA nodes in a way that may present a problem for !tbaa but not !tbaa.struct nodes. Differential Revision: https://reviews.llvm.org/D99851
Currently, the InstCombineCompare is combining two add operations into a single add operation which always has a nsw flag, without checking the conditions to see if this flag should be present according to the original two add operations or not. This patch will change the InstCombineCompare to emit the nsw or nuw only when these flags are allowed to be generated according to the original add operations and remove the possibility of applying wrong optimization with passes that will perform on the IR later in the pipeline. To confirm that the current results are buggy and the results after proposed patch are the correct IR the following examples from Alive2 are attached; the same results can be seen in the case of nuw flag and nsw is just used as an example. The following link shows that the generated IR with current LLVM is a buggy IR when none of the original add operations have nsw flag. https://alive2.llvm.org/ce/z/WGaDrm The following link proves that the generated IR after the patch in the former case is the correct IR. https://alive2.llvm.org/ce/z/wQ7G_e Differential Revision: https://reviews.llvm.org/D100095
These were in the shared llgs+platform code, but they only make sense for llgs (as they deal with how the server reports information about debugged processes).
This functionality is used exactly once, and it is trivial to implement it differently (capture into two distinct variables, and compare for equality afterwards).
It looks like the goal of this code is to provide a more precise architecture definition for the target when attaching to a process. When attaching to a foreign debugserver, you might get into a situation where the active (host) platform will give you bogus information on the target process. This change allows the platform to override the target arch only with a compatible architecture. This fixes TestTargetXMLArch.py on Apple Silicon. Another alternative would be to just fail in this scenario and update the test(s).
… and convertFromStorage (NFC) Differential Revision: https://reviews.llvm.org/D100356
This reverts commit a32846b. The build is broken with -DBUILD_SHARED_LIBS=ON: tools/mlir/lib/Reducer/CMakeFiles/obj.MLIRReduce.dir/Tester.cpp.o: In function `mlir::Tester::isInteresting(mlir::ModuleOp) const': Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xa8): undefined reference to `mlir::OpPrintingFlags::OpPrintingFlags()' Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xc6): undefined reference to `mlir::Operation::print(llvm::raw_ostream&, mlir::OpPrintingFlags)'
Instead of managing memory by hand, delegate it to std::vector. This makes the code much simpler, and also avoids repeatedly computing the storage size. According to valgrind --tool=callgrind, this also slightly decreases the instruction count, but by a small margin. Differential Revision: https://reviews.llvm.org/D100387
Now that 9b8e7a9 ("[lli] Honor the --entry-function flag in orc and orc-lazy modes") fixed https://llvm.org/PR49906. Reviewed By: mehdi_amini, aartbik Differential Revision: https://reviews.llvm.org/D100407
Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 20000 events fired. Sending all these events to the IDE can break it. For example, debugging a huge binary resulted in around 50 million messages, which rendered the IDE useless, as it was spending all of its resources simply parsing messages and updating the UI. A way to fix this is to send unique percentage updates, which are at most 100 per job, which is not much. I was able to debug that big target and confirm that only unique percentage notifications are sent. I can't write a test for this because the current test is flaky. I'll figure out later how to make the test reliable, but fixing this will unblock us from deploy a new version of lldb-vscode. Differential Revision: https://reviews.llvm.org/D100443
As was done for other locations in commit 54272e5 (NFC: Replace asserts with if() in SourceLocation accessors, 2019-01-07). Extracted from https://reviews.llvm.org/D99231
Fix the logic of detecting pseudo-virtual getBeginLoc etc on Stmt and Decl subclasses. Adjust the test infrastructure to filter out invalid source locations. This makes the tests more clear about which nodes have which locations. Differential Revision: https://reviews.llvm.org/D99231
Add iterator for ReductionNode traversal and use range to indicate the region we would like to keep. Refactor the interaction between Pass/Tester/ReductionNode. Now it'll be easier to add new traversal type and OpReducer Reviewed By: jpienaar, rriddle Differential Revision: https://reviews.llvm.org/D99713
Removes the builtins and intrinsics used to opt in to using these instructions and replaces them with normal ISel patterns now that they are no longer prototypes. Differential Revision: https://reviews.llvm.org/D100402
This fixes TestGdbRemoteHostInfo on Apple Silicon.
We are able to config the reducer pass pipeline through command-line. Reviewed By: jpienaar, rriddle Differential Revision: https://reviews.llvm.org/D100155
Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D100156
We have some cases today where attributes can be inferred from another on access, but the result is not explicitly materialized in IR. This change is a step towards changing that. Why? Two main reasons: * Human clarity. It's really confusing trying to figure out why a transform is triggering when the IR doesn't appear to have the required attributes. * This avoids the need to special case declarations in e.g. functionattrs. Since we can assume the attribute is present, we can work directly from attributes (and only attributes) without also needing to query accessors on Function to avoid missing cases due to unannotated (but infered on use) declarations. (This piece will appear must easier to follow once D100226 also lands.) Differential Revision: https://reviews.llvm.org/D100400
About to refresh a patch that uses this in FunctionAtrrs, doing the move seperately to control build times.
An inadvertent ! operator was (fortunately) flagged as a warning by clang; remove it. Differential Review: https://reviews.llvm.org/D100513
The run method is only called if there is a match with a binding.
DWARF allows .dwo file paths to be relative rather than absolute. When they are relative, DWARF uses DW_AT_comp_dir to find the .dwo file. DW_AT_comp_dir can also be relative, making the entire search patch for the .dwo file relative. In this case, LLDB currently searches relative to its current working directory, i.e. the directory from which the debugger was launched. This is not right, as the compiler, which generated the relative paths, can have no idea where the debugger will be launched. The correct thing is to search relative to the location of the executable binary. That is what this patch does. Differential Revision: https://reviews.llvm.org/D97786
As mentioned in https://gcc.gnu.org/PR100114 , glibc starting with the https://sourceware.org/git/?p=glibc.git;a=commit;h=6c57d320484988e87e446e2e60ce42816bf51d53 change doesn't define SIGSTKSZ and MINSIGSTKSZ macros to constants, but to sysconf function call. sanitizer_posix_libcdep.cpp has static const uptr kAltStackSize = SIGSTKSZ * 4; // SIGSTKSZ is not enough. which is generally fine, just means that when SIGSTKSZ is not a compile time constant will be initialized later. The problem is that kAltStackSize is used in SetAlternateSignalStack which is called very early, from .preinit_array initialization, i.e. far before file scope variables are constructed, which means it is not initialized and mmapping 0 will fail: ==145==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of SetAlternateSignalStack (error code: 22) Here is one possible fix, another one could be to make kAltStackSize a preprocessor macro if _SG_SIGSTKSZ is defined (but perhaps with having an automatic const variable initialized to it so that sysconf isn't at least called twice during SetAlternateSignalStack. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D100645
This patch clarifies the semantics of the nofree function attribute to make clear that it provides an "as if" semantic. That is, a nofree function is guaranteed not to free memory which existed before the call, but might allocate and then deallocate that same memory within the lifetime of the callee. This is the result of the discussion on llvm-dev under the thread "Ambiguity in the nofree function attribute". The most important part of this change is the LangRef wording. The rest is minor comment changes to emphasize the new semantics where code was accidentally consistent, and fix one place which wasn't consistent. That one place is currently narrowly used as it is primarily part of the ongoing (and not yet enabled) deref-at-point semantics work. Differential Revision: https://reviews.llvm.org/D100141
This amends 0cb7e7c. The iterator category of lookup_iterator was changed, but here it stayed hardcoded as random access. Found while trying to build Clazy. Differential-Revision: https://reviews.llvm.org/D100590
Use the target-independent @llvm.fptosi and @llvm.fptoui intrinsics instead.
This includes removing the instrinsics for i32x4.trunc_sat_zero_f64x2_{s,u},
which are now represented in IR as a saturating truncation to a v2i32 followed by
a concatenation with a zero vector.
Differential Revision: https://reviews.llvm.org/D100596
Change the default to facilitate GC for metadata section usage, so that they don't need SHF_LINK_ORDER or SHF_GROUP just to drop the unhelpful rule (if they want to be unconditionally retained, use SHF_GNU_RETAIN (`__attribute__((retain))`) or linker script `KEEP`). The dropped SHF_GROUP special case makes the behavior of -z start-stop-gc and -z nostart-stop-gc closer to GNU ld>=2.37 (https://sourceware.org/PR27451). However, we default to -z start-stop-gc (which actually matches more closely to GNU ld before 2015-10 https://sourceware.org/PR19167), which is different from modern GNU ld (which has the unhelpful rule to work around glibc). As a compensation, we special case `__libc_` sections as a workaround for glibc<2.34 (https://sourceware.org/PR27492). Since -z start-stop-gc as the default actually matches the traditional GNU ld behavior, there isn't much to be aware of. There was a systemd usage which has been fixed by systemd/systemd#19144
Add a code and data address mask to Process with respective getters and setters and a setting that allows the user to specify the mast as a number of addressable bits. The masks will be used by FixCodeAddress and FixDataAddress respectively in the ABI classes. Differential revision: https://reviews.llvm.org/D100515
Reviewed By: kzhuravl Differential Revision: https://reviews.llvm.org/D100679
…name in addition to the HwMode flag. This was causing GenerateVariants to lose some variants since HwMode is expanded first. We were mistakenly thinking the HwMode predicate matched and finding the variant was isomorphic to a pattern in another HwMode and discarding it. Found while investigating it if would be better to generate variants before expanding HwModes to improve RISCV build time. I noticed an increase in the number of Opc_MorphNodeTo in the table which indicated that the number of patterns had changed.
Gives reasoning for convertDPP8. Also corrects typo in Operand type comment. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D100665 Change-Id: I33ff269db8072d83e5e0ecdbfb731d6000fc26c4
These lines set the value to what it already was, so they are redundant. NFC Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D100664 Change-Id: Ibf6f27d50a7fa1f76c127f01b799821378bfd3b3
This diff creates an empty XAR file and copies it into `__LLVM,__bundle`. Follow-up work will actually populate the contents of that XAR. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D100650
Instead of managing memory by hand, delegate it to std::vector. This makes the code much simpler, and also avoids repeatedly computing the storage size. According to valgrind --tool=callgrind, this also slightly decreases the instruction count, but by a small margin. This is a recommit of 82f0e3d with one usage fixed in llvm/lib/CodeGen/RegisterScavenging.cpp. Not the slight API change: BitVector::clear() now has the same behavior as any other container: it does not free memory, but indeed sets the size of the BitVector to 0. It is thus incorrect to access its content right afterwards, a scenario which wasn't enforced in previous implementation. Differential Revision: https://reviews.llvm.org/D100387
Implement FixCodeAddress and FixDataAddress for ABIMacOSX_arm64 and ABISysV_arm64 and add missing calls to RegisterContextUnwind. We need this to unwind on Apple Silicon where libraries like libSystem are arm64e even when the program being debugged is arm64. Differential revision: https://reviews.llvm.org/D100521
Read the number of addressable bits from the qHostInfo packet and use it to set the code and data address mask in the process. The data (addressing_bits) is already present in the packet. Differential revision: https://reviews.llvm.org/D100520
GNU ld 2.26 and GNU ld 2.31 seem fine but GNU ld 2.30 has mysterious segfaults linking msan tests.
I think this should unbreak the build after D100650...
This patch provides `TYPED_TEST` and `TYPED_TEST_F` (similar in functionnality to gtest).
This is needed to extensively test building blocks for memory functions.
Example for `TYPED_TEST_F`:
```
template <typename T> class LlvmLibcMyTestFixture : public testing::Test {};
using Types = testing::TypeList<char, int, long>;
TYPED_TEST_F(LlvmLibcMyTestFixture, Simple, Types) {
EXPECT_LE(sizeof(ParamType), 8UL);
}
```
Example for `TYPED_TEST`:
```
using Types = testing::TypeList<char, int, long>;
TYPED_TEST(LlvmLibcMyTest, Simple, Types) {
EXPECT_LE(sizeof(ParamType), 8UL);
}
```
`ParamType` is displayed as fully qualified canonical type which can be difficult to read, the user can provide a more readable name by using the `REGISTER_TYPE_NAME` macro.
Differential Revision: https://reviews.llvm.org/D100631
…merge-upstream-20210416
Closed
kaz7
pushed a commit
that referenced
this pull request
Aug 14, 2021
There is a SIGSEGV at `DeduceTemplateArgumentsByTypeMatch`. The bug [#51171](https://bugs.llvm.org/show_bug.cgi?id=51171) was filled. The reproducer can be found at the bug description. LIT test for the issue was added: ``` ./bin/llvm-lit -v ../clang/test/SemaCXX/pr51171-crash.cpp ``` The debug stack trace is below: ``` #0 0x00000000055afcb9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:22 #1 0x00000000055afd70 PrintStackTraceSignalHandler(void*) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1 #2 0x00000000055add2d llvm::sys::RunSignalHandlers() /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Signals.cpp:97:20 #3 0x00000000055af701 SignalHandler(int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1 #4 0x00007ffff7bc2b20 __restore_rt sigaction.c:0:0 #5 0x00007ffff66a337f raise (/lib64/libc.so.6+0x3737f) #6 0x00007ffff668ddb5 abort (/lib64/libc.so.6+0x21db5) #7 0x00007ffff668dc89 _nl_load_domain.cold.0 loadmsgcat.c:0:0 #8 0x00007ffff669ba76 .annobin___GI___assert_fail.end assert.c:0:0 #9 0x000000000594b210 clang::QualType::getCommonPtr() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:684:5 #10 0x0000000005a12ca6 clang::QualType::getCanonicalType() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:6467:36 #11 0x0000000005a137a6 clang::ASTContext::getCanonicalType(clang::QualType) const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/ASTContext.h:2433:58 #12 0x0000000009204584 DeduceTemplateArgumentsByTypeMatch(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:1355:54 #13 0x000000000920df0d clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4354:47 #14 0x0000000009012b09 (anonymous namespace)::AddressOfFunctionResolver::AddMatchingTemplateFunction(clang::FunctionTemplateDecl*, clang::DeclAccessPair const&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12026:38 #15 0x0000000009013030 (anonymous namespace)::AddressOfFunctionResolver::FindAllFunctionsThatMatchTargetTypeExactly() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12119:9 #16 0x0000000009012679 (anonymous namespace)::AddressOfFunctionResolver::AddressOfFunctionResolver(clang::Sema&, clang::Expr*, clang::QualType const&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:11931:5 #17 0x0000000009013c91 clang::Sema::ResolveAddressOfOverloadedFunction(clang::Expr*, clang::QualType, bool, clang::DeclAccessPair&, bool*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12286:42 #18 0x0000000008fed85d IsStandardConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::StandardConversionSequence&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1712:49 #19 0x0000000008fec8ea TryImplicitConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::Sema::AllowedExplicit, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1433:27 #20 0x0000000008ff90ba TryCopyInitialization(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:5273:71 #21 0x00000000090024fb clang::Sema::AddBuiltinCandidate(clang::QualType*, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&, bool, unsigned int) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:7755:32 #22 0x000000000900513f (anonymous namespace)::BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:8633:30 #23 0x0000000009007624 clang::Sema::AddBuiltinOperatorCandidates(clang::OverloadedOperatorKind, clang::SourceLocation, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:9205:51 #24 0x0000000009018734 clang::Sema::LookupOverloadedBinOp(clang::OverloadCandidateSet&, clang::OverloadedOperatorKind, clang::UnresolvedSetImpl const&, llvm::ArrayRef<clang::Expr*>, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13469:1 #25 0x0000000009018d56 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*, bool, bool, clang::FunctionDecl*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13568:24 #26 0x0000000008b24797 BuildOverloadedBinOp(clang::Sema&, clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14606:65 #27 0x0000000008b24ed5 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14691:73 #28 0x0000000008b245d4 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14566:1 #29 0x00000000085bfafb clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*, true>, clang::prec::Level) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:630:71 #30 0x00000000085bd922 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:177:1 #31 0x00000000085cbbcd clang::Parser::ParseExpressionList(llvm::SmallVectorImpl<clang::Expr*>&, llvm::SmallVectorImpl<clang::SourceLocation>&, llvm::function_ref<void ()>) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:3368:40 #32 0x000000000857f49c clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2416:5 #33 0x000000000857df16 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2092:65 #34 0x000000000855f07b clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1138:1 #35 0x000000000855f136 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1153:57 #36 0x000000000855e644 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:975:58 #37 0x000000000855d717 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:720:42 #38 0x0000000008558e01 clang::ParseAST(clang::Sema&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseAST.cpp:158:37 #39 0x000000000627a221 clang::ASTFrontendAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1058:11 #40 0x0000000006bdcc31 clang::CodeGenAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1045:5 #41 0x0000000006279b4d clang::FrontendAction::Execute() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:955:38 #42 0x00000000061c3fe9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:974:42 #43 0x00000000063f9c5e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/ivanmurashko/local/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:38 #44 0x0000000002603a03 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /home/ivanmurashko/local/llvm-project/clang/tools/driver/cc1_main.cpp:246:40 #45 0x00000000025f8a39 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:338:20 #46 0x00000000025f9107 main /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:415:26 #47 0x00007ffff668f493 __libc_start_main (/lib64/libc.so.6+0x23493) #48 0x00000000025f729e _start (/data/users/ivanmurashko/llvm-project/build/bin/clang-13+0x25f729e) ``` Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D106583
kaz7
pushed a commit
that referenced
this pull request
May 22, 2023
…callback
The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.
`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:
```
int main() {
std::unique_ptr<int> up = std::make_unique<int>(5);
volatile int val = *up;
return val;
}
clang++ -std=c++2a -g -O1 main.cpp
./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```
```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame #27: lldb_private::SwiftASTContext::LoadModule
frame #30: swift::ModuleDecl::collectLinkLibraries
frame #31: lldb_private::SwiftASTContext::LoadModule
frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame #38: lldb_private::Target::GetPersistentSymbol
frame #41: lldb_private::TypeSystemMap::ForEach <<<< Lock #1
frame #42: lldb_private::Target::GetPersistentSymbol
frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame #44: lldb_private::IRExecutionUnit::FindSymbol
frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #48: llvm::LinkingSymbolResolver::findSymbol
frame #49: llvm::LegacyJITSymbolResolver::lookup
frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame #51: llvm::RuntimeDyldImpl::resolveRelocations
frame #52: llvm::MCJIT::finalizeLoadedModules
frame #53: llvm::MCJIT::finalizeObject
frame #54: lldb_private::IRExecutionUnit::ReportAllocations
frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame #56: lldb_private::ClangExpressionParser::PrepareForExecution
frame #57: lldb_private::ClangUserExpression::TryParse
frame #58: lldb_private::ClangUserExpression::Parse
```
Our solution is to simply iterate over a local copy of `m_map`.
**Testing**
* Confirmed on manual reproducer (would reproduce 100% of the time
before the patch)
Differential Revision: https://reviews.llvm.org/D149949
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge upto 2021/4/16 upstream/main.
Pass regression tests.