[pull] swiftwasm-release/5.3 from swift/release/5.3 #5
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
value as undefined
- Correct a debug info salvage and add a test
Reviewers: aprantl, vsk
Differential Revision: https://reviews.llvm.org/D76930
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=45080
(cherry picked from commit 135709a)
…PR45259) In InnerLoopVectorizer::getOrCreateTripCount, when the backedge taken count is a SCEV add expression, its type is defined by the type of the last operand of the add expression. In the test case from PR45259, this last operand happens to be a pointer, which (according to llvm::Type) does not have a primitive size in bits. In this case, LoopVectorize fails to truncate the SCEV and crashes as a result. Uing ScalarEvolution::getTypeSizeInBits makes the truncation work as expected. https://bugs.llvm.org/show_bug.cgi?id=45259 Differential Revision: https://reviews.llvm.org/D76669 (cherry picked from commit dcc410b)
…sing DWARF When parsing DWARF and laying out bit-fields we currently don't take into account whether we have a base class or not. Currently if the first field is a bit-field but the bit offset is due a field we inherit from a base class we currently treat it as an unnamed bit-field and therefore add an extra field. This fix will not check if we have a base class and assume that this offset is due to members we are inheriting from the base. We are currently seeing asserts during codegen when debugging clang::DiagnosticOptions. This assumption will fail in the case where the first field in the derived class in an unnamed bit-field. Fixing the first field being an unnamed bit-field looks like it will require a larger change since we will need a way to track or discover the last field offset of the bases(s). Differential Revision: https://reviews.llvm.org/D76808 (cherry picked from commit 00c8120)
Cherry-pick DSE debug info fix, fix loopvectorize crash
In order to run check-lldb-* we need the correct map_config directives in llvm-lit. For the standalone build, LLVM doesn't know about LLDB, and the lldb mappings are missing. In that case we build our own llvm-lit, and tell LLVM to use the llvm-lit in the lldb build directory. Differential revision: https://reviews.llvm.org/D76945 (cherry picked from commit 63aaecd)
Re-enable tests working on Linux
…warf_when_base_class [LLDB] Fix handling of bit-fields when there is a base class when parsing DWARF
CPlusPlusNameParser is used in several places on of them is during IR execution and setting breakpoints to pull information C++ like the basename, the context and arguments. Currently it does not handle templated operator< properly, because of idiosyncrasy is how clang generates debug info for these cases. It uses clang::Lexer which will tokenize operator<<A::B> into: tok::kw_operator tok::lessless tok::raw_identifier Later on the parser in ConsumeOperator() does not handle this case properly and we end up failing to parse. Differential Revision: https://reviews.llvm.org/D76168 (cherry picked from commit 8016d61)
Found by msan. (cherry picked from commit 3806b38)
…2cd4b4f2b42183978fd30ddef [lldb/CMake] Make check-lldb-* work for the standalone build.
Summary: The ValueObject code checks for a special `$$dereference$$` synthetic child to allow formatter providers to implement a natural dereferencing behavior in `frame variable` for objects like smart pointers. This support was broken when used directly throught the Python API and not trhough `frame variable`. The reason is that SBFrame.FindVariable() will return by default the synthetic variable if it exists, while `frame variable` will not do this eagerly. The code in `ValueObject::Dereference()` accounted for the latter but not for the former. The fix is trivial. The test change includes additional covergage for the already-working bahevior as it wasn't covered by the testsuite before. This commit also adds a short piece of documentatione explaining that it is possible (even advisable) to provide this synthetic child outstide of the range of the normal children. Reviewers: jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73053 (cherry picked from commit 0478ead)
[lldb/DataFormatters] Fix the `$$deference$$` synthetic child
…handle_temp_operator_less CPlusPlusNameParser does not handles templated operator< properly
This patch fixes a crash that happens on the DWARF expression evaluator when trying to access the top of the stack while it's empty. rdar://60512489 Differential Revision: https://reviews.llvm.org/D77108 Signed-off-by: Med Ismail Bennani <[email protected]>
[lldb/DWARF] Fix evaluator crash when accessing empty stack.
Implement TypeSystemSwiftTypeRef::IsArrayType()
Move all unimplemented Swift Typesystem functions into the base class (NFC)
This didn't happen for arm64 if you have watches for variables that are contigous in memory. <rdar://problem/55135006>
… status Previously we would emit a PCH with errors, but fail the overall compilation. If run using the driver, that would result in removing the just-produced PCH. Instead, we should have the compilation result match whether we were able to emit the PCH. Differential Revision: https://reviews.llvm.org/D77159 rdar://61110294
Per the documentation, this class is supposed to forward every virtual method, but we had missed on (shouldEraseOutputFiles). This fixes using a wrapped frontend action over the PCH generator when using -fallow-pch-with-compiler-errors. I do not think any upstream wrapper actions can test this. Differential Revision: https://reviews.llvm.org/D77180 rdar://61110294
[Swift] Replace calls to FuncDecl::getName & EnumElementDecl::getName with ValueDecl::getBaseIdentifier
[20200108] [pch] Honour -fallow-pch-with-compiler-errors for overall compilation status
Fix unknown type cast crash
Implement TypeSystemSwiftTypeRef::GetFunctionReturnType() (NFC)
[lldb/DataFormatters] SwiftHashedContainer: Validate m_scale
Cherry-pick more patches for <rdar://problem/58789439>
…e to covariant return types Summary: Currently we crash in Clang's CodeGen when we call functions with covariant return types with this assert: ``` Assertion failed: (DD && "queried property of class with no definition"), function data, file clang/include/clang/AST/DeclCXX.h, line 433. ``` when calling `clang::CXXRecordDecl::isDerivedFrom` from the `ItaniumVTableBuilder`. Clang seems to assume that the underlying record decls of covariant return types are already completed. This is true during a normal Clang invocation as there the type checker will complete both decls when checking if the overloaded function is valid (i.e., the return types are covariant). When we minimally import our AST into the expression in LLDB we don't do this type checking (which would complete the record decls) and we end up trying to access the invalid record decls from CodeGen which makes us trigger the assert. This patch just completes the underlying types of ptr/ref return types of virtual function so that the underlying records are complete and we behave as Clang expects us to do. Fixes rdar://38048657 Reviewers: lhames, shafik Reviewed By: shafik Subscribers: abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73024 (cherry picked from commit a5fb2e3)
Summary: D73024 seems to have fixed one set crash, but it introduced another. Namely, if a class contains a covariant method returning itself, the logic in MaybeCompleteReturnType could cause us to attempt a recursive import, which would result in an assertion failure in clang::DeclContext::removeDecl. For some reason, this only manifested itself if the class contained at least two member variables, and the class itself was imported as a result of a recursive covariant import. This patch fixes the crash by not attempting to import classes which are already completed in MaybeCompleteReturnType. However, it's not clear to me if this is the right fix, or if this should be handled automatically by functions lower in the stack. Reviewers: teemperor, shafik Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D76840 (cherry picked from commit 7b00eeb)
…-textual-headers [Modules] Add more x86 textual headers to the module map
…pe_handling fix covariant return type handling
Fix a bug where UnwindAssemblyInstEmulation would confuse which register is used to compute the Canonical Frame Address after it had branched over a mid-function epilogue (where the CFA reg changes from $fp to $sp in the process of epiloguing). Reinstate the correct CFA register after we forward the unwind rule for branch targets. The failure mode was that UnwindAssemblyInstEmulation would think CFA was set in terms of $sp after one of these epilogues, and if it sees modifications to $sp after the branch target, it would change the CFA offset in the unwind rule -- even though the CFA is defined in terms of $fp and the $sp changes are irrelevant to correct calculation. <rdar://problem/60300528> Differential Revision: https://reviews.llvm.org/D78077 (cherry picked from commit 1cd92e4)
… in the synthesized AST" This reverts commit 3c58b0f while investigating a downstream Swift DWARFImporter problem.
The current strategy LICM uses when sinking for debuginfo is that of picking the debug location of one of the uses. This causes stepping to be wrong sometimes, see, e.g. PR45523. This patch introduces a generalization of getMergedLocation(), that operates on a vector of locations instead of two, and try to merge all them together, and use the new API in LICM. <rdar://problem/61750950>
Check if objc runtime pointer is null before using it
Temporarily revert "Preserve the owning module information from DWARF…
[LICM] Try to merge debug locations when sinking.
The SIP debugserver was calling in attach_failed_due_to_sip haven't worked for a while; remove them. To check this properly we'd need debugsever to call out to codesign(1) to inspect the entitlements, or the equivalant API, and I'm not interested in adding that at this point. SIP is has been the default on macOS for a couple of releases and it's expected behavior now. <rdar://problem/59198052> (cherry picked from commit 7fa342b)
Update for the removal of the LLVMContext parameter
…ut plan. I have two reports of lldb crashing because the callback said it had a way to get out from here, but then failed to produce a plan to do so. I don't know why this happens, but in any case, we should stop in response to the failure, not crash. <rdar://problem/60642337>
…is called during the LateInitialize stage of the sanitizer runtimes. Summary: This is implemented by adding a `Symbolizer::LateInitializeTools()` method that iterates over the registered tools and calls the `LateInitialize()` method on them. `Symbolizer::LateInitializeTools()` is now called from the various `Symbolizer::LateInitialize()` implementations. The default implementation of `SymbolizerTool::LateInitialize()` does nothing so this change should be NFC. This change allows `SymbolizerTool` implementations to perform any initialization that they need to perform at the LateInitialize stage of a sanitizer runtime init. rdar://problem/58789439 Reviewers: kubamracek, yln, vitalybuka, cryptoad, phosek, rnk Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D78178 (cherry picked from commit fccea7f)
Summary: Due to sandbox restrictions in the recent versions of the simulator runtime the atos program is no longer able to access the task port of a parent process without additional help. This patch fixes this by registering a task port for the parent process before spawning atos and also tells atos to look for this by setting a special environment variable. This patch is based on an Apple internal fix (rdar://problem/43693565) that unfortunately contained a bug (rdar://problem/58789439) because it used setenv() to set the special environment variable. This is not safe because in certain circumstances this can trigger a call to realloc() which can fail during symbolization leading to deadlock. A test case is included that captures this problem. The approach used to set the necessary environment variable is as follows: 1. Calling `putenv()` early during process init (but late enough that malloc/realloc works) to set a dummy value for the environment variable. 2. Just before `atos` is spawned the storage for the environment variable is modified to contain the correct PID. A flaw with this approach is that if the application messes with the atos environment variable (i.e. unsets it or changes it) between the time its set and the time we need it then symbolization will fail. We will ignore this issue for now but a `DCHECK()` is included in the patch that documents this assumption but doesn't check it at runtime to avoid calling `getenv()`. The issue reported in rdar://problem/58789439 manifested as a deadlock during symbolization in the following situation: 1. Before TSan detects an issue something outside of the runtime calls setenv() that sets a new environment variable that wasn't previously set. This triggers a call to malloc() to allocate a new environment array. This uses TSan's normal user-facing allocator. LibC stores this pointer for future use later. 2. TSan detects an issue and tries to launch the symbolizer. When we are in the symbolizer we switch to a different (internal allocator) and then we call setenv() to set a new environment variable. When this happen setenv() sees that it needs to make the environment array larger and calls realloc() on the existing enviroment array because it remembers that it previously allocated memory for it. Calling realloc() fails here because it is being called on a pointer its never seen before. The included test case closely reproduces the originally reported problem but it doesn't replicate the `((kBlockMagic)) == ((((u64*)addr)[0])` assertion failure exactly. This is due to the way TSan's normal allocator allocates the environment array the first time it is allocated. In the test program addr[0] accesses an inaccessible page and raises SIGBUS. If TSan's SIGBUS signal handler is active, the signal is caught and symbolication is attempted again which results in deadlock. In the originally reported problem the pointer is successfully derefenced but then the assert fails due to the provided pointer not coming from the active allocator. When the assert fails TSan tries to symbolicate the stacktrace while already being in the middle of symbolication which results in deadlock. rdar://problem/58789439 Reviewers: kubamracek, yln Subscribers: jfb, #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D78179 (cherry picked from commit 861b69f)
Cherry pick rdar://problem/58789439 part3
Fixes a bug in Sema where it was incorrectly rejecting the following
code:
```
typedef void * __ptrauth(ptrauth_key_process_dependent_data, 1, 42) T;
bool compare(T *a, T *b) {
return a == b;
}
```
rdar://problem/54603670
Don't drop ptrauth qualifiers when constructing C++ composite types
Verify that the ShouldStopHere callback actually can produce a step o…
MaxDesiatov
pushed a commit
that referenced
this pull request
Sep 4, 2020
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned `entry_addr` is valid, it can immediately be returned. However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: ``` * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890``` Fix the incorrect error catch by only instantiating an `Error` object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 (cherry picked from commit 1ce07cd)
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.
See Commits and Changes for more details.
Created by
pull[bot]. Want to support this open source service? Please star it : )