[AArch64][GlobalISel] Fix TLS accesses clobbering registers incorrectly. #232
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
The FileSpec constructor takes a StringRef so there's no point in going through a C string. (cherry picked from commit 6e69338)
…kpoint command is invalid Summary: Currently the breakpoint command is prompting the user to file a bug report if the provided regex is invalid: ``` (lldb) rbreak *foo error: Function name regular expression could not be compiled: "Inconvertible error value. An error has occurred that could not be converted to a known std::error_code. Please file a bug. repetition-operator operand invalid" ``` The reason is simply that we are using the wrong StringError constructor (the one with the error code as the first parameter is also printing the string version of the error code, and the inconvertible error code is just an invalid place holder code with that description). Switching the StringError constructor parameters will only print the error message we get from the regex engine when we convert the error into a string. I checked the rest of the code base and I couldn't find the same issue anywhere else. Fixes rdar://62233561 Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D78808 (cherry picked from commit b58af8d)
(cherry picked from commit e327ea4)
[lldb] Improve error message when --func-regex parameter for the brea…
[lldb/Platform] Synchronize access to SDK String Map. …
Fix a dangling-gsl warning and avoid transitively including string.
[AST] Fix a crash on a dependent vector_size attribute
…3e39ea58643aef88bd [lldb] Fix typo in breakpoint set -r description
Summary: This was originally commented out as it broke the data-formatter-stl/libcxx/ tests. However this was fixed by commit ef423a3 (Add Objective-C property accessors loaded from Clang module DWARF to lookup) which sets the HasExternalVisibleStorage flag for the template specializations. Reviewers: aprantl Reviewed By: aprantl Subscribers: abidh, JDevlieghere Differential Revision: https://reviews.llvm.org/D79168 (cherry picked from commit 8e9fb84)
This reverts commit b14c37a.
Revert "[lldb/Platform] Return a std::string from GetSDKPath"
Summary: Have stripNonLineTableDebugInfo() attach updated !llvm.loop metadata to an instruction (instead of updating and then discarding the metadata). This fixes "!dbg attachment points at wrong subprogram for function" errors seen while archiving an iOS app. It would be nice -- as a follow-up -- to catch this issue earlier, perhaps by modifying the verifier to constrain where DILocations are allowed. Any alternative suggestions appreciated. rdar://61982466 Reviewers: aprantl, dsanders Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79200 (cherry picked from commit 9350792)
[DebugInfo] Update loop metadata in stripNonLineTableDebugInfo
When trying to read a core file that is not owned by the user running lldb and that doesn't have read permission on the file, lldb shows a misleading error message: ``` Unable to find process plug-in for core file ``` This is due to the fact that currently, lldb doesn't check the file ownership. And when trying to to open and read a core file, the syscall fails, which prevents a process to be created. Since lldb already have a portable `open` syscall interface, lets take advantage of that and delegate the error handling to the syscall itself. This way, no matter if the file exists or if the user has proper ownership, lldb will always try to open the file, and behave accordingly to the error code returned. rdar://42630030 https://reviews.llvm.org/D78712 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes the test failure happening on Windows introduced by `015117411e11458f9816ba4359246132164a4297`. Since the failure message comes from the OS, the test needs to support both UNIX and Windows messages. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb/Host] Improve error messages on unowned read files
We were creating a bunch of LineSequence objects but never deleting them. This fixes the leak and changes the code to use std::unique_ptr, to make it harder to make the same mistake again.
[lldb/DWARF] Fix a leak in line table construction
This reverts commit f4db8e0. This was cherry-picked incorrectly
…on sort Summary: Motivation: When setting breakpoints in certain projects line sequences are frequently being inserted out of order. Rather than inserting sequences one at a time into a sorted line table, store all the line sequences as we're building them up and sort and flatten afterwards. Reviewers: jdoerfert, labath Reviewed By: labath Subscribers: teemperor, labath, mgrang, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72909 (cherry picked from commit 39f1335)
This addresses some post-commit feedback on D72909. (cherry picked from commit 3f9b6b2)
We were creating a bunch of LineSequence objects but never deleting them. This fixes the leak and changes the code to use std::unique_ptr, to make it harder to make the same mistake again. (cherry picked from commit 18a96fd)
Fix linetables leak
Update CallBoardSystemServiceOpenApplication to unconditionally log the NSError's localizedDescription to Console on app launch failure (as it was already doing), and also to log the NSError object's full description to the console, which may contain additional nested error messages. I'm experimenting to find cases where we will get more detailed information from app launch failures and will start by logging both to the console. <rdar://problem/62709160> (cherry picked from commit 5034102)
…ject Log the NSError str and object description on app launch fail
…e units When debugging from a SymbolMap the creation of CompileUnits for the individual object files is so lazy that RegisterXcodeSDK() is not invoked at all before the Swift TypeSystem wants to read it. This patch fixes this by introducing an explicit SymbolFile::ParseXcodeSDK() call that can be invoked deterministically before the result is required. <rdar://problem/62532151+62326862> https://reviews.llvm.org/D79273 (cherry picked from commit 5935227)
When debugging a remote platform, the platform you get from GetPlatformForArchitecture doesn't inherit from PlatformDarwin. HostInfoMacOSX seems like the right place to have a global store of local paths. Differential Revision: https://reviews.llvm.org/D79364 (cherry picked from commit f0c08b7)
For Swift LLDB (but potentially also for module support in Clang-land) we need a way to accumulate the path remappings produced by Module::RegisterXcodeSDK(). In order to make this work for SymbolFileDebugMaps, registering the search path remapping with both modules is necessary. Differential Revision: https://reviews.llvm.org/D79384 <rdar://problem/62750529> (cherry picked from commit 01fc85d)
…rship Backport template specialization ownership commits
Unlike other platforms using ItaniumCXXABI, Darwin does not allow the creation of a thread-wrapper function for a variable in the TU of users. Because of this, it can set the linkage of the thread-local symbol to internal, with the assumption that no TUs other than the one defining the variable will need it. However, constinit thread_local variables do not require the use of the thread-wrapper call, so users reference the variable directly. Thus, it must not be converted to internal, or users will get a link failure. This was a regression introduced by the optimization in 0022382. Differential Revision: https://reviews.llvm.org/D80417 (cherry picked from commit aca3d06)
Adds `CodeGen::getCXXDestructorImplicitParam`, to retrieve a C++ destructor's implicit parameter (after the "this" pointer) based on the ABI in the given CodeGenModule. This will allow other frontends (Swift, for example) to easily emit calls to object destructors with correct ABI semantics and calling convetions. This is needed for Swift C++ interop. Here's the corresponding Swift change: swiftlang/swift#32291 Differential Revision: https://reviews.llvm.org/D82392
Fix Darwin 'constinit thread_local' variables.
Cherry-pick from upstream: [CodeGen] Add public function to get the implicit C++ destructor argument (if existent).
to detect energy support in debugserver. The way that Swift build-script is invoked the former may be overridden manually. <rdar://problem/63840635> (cherry picked from commit 60c07fd)
Use CMAKE_OSX_SYSROOT instead of the environment variable SYSROOT
Summary: A lot of our tests do 'self.assertTrue(error.Success()'. The problem with that is that when this fails, it produces a completely useless error message (False is not True) and the most important piece of information -- the actual error message -- is completely hidden. Sometimes we mitigate that by including the error message in the "msg" argument, but this has two additional problems: - as the msg argument is evaluated unconditionally, one needs to be careful to not trigger an exception when the operation was actually successful. - it requires more typing, which means we often don't do it assertSuccess solves these problems by taking the entire SBError object as an argument. If the operation was unsuccessful, it can format a reasonable error message itself. The function still accepts a "msg" argument, which can include any additional context, but this context now does not need to include the error message. To demonstrate usage, I replace a number of existing assertTrue assertions with the new function. As this process is not easily automatable, I have just manually updated a representative sample. In some cases, I did not update the code to use assertSuccess, but I went for even higher-level assertion apis (runCmd, expect_expr), as these are even shorter, and can produce even better failure messages. Reviewers: teemperor, JDevlieghere Subscribers: arphaman, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D82759 (cherry picked from commit 3567497)
io.BytesIO seems to produce a stream in Python 2 which isn't recognized as a file object in the SWIG API, so this test fails for Python 2 (and I assume also an old SWIG version needs to be involved). Instead just open an empty input file which is a file object in all Python versions to make this test pass everywhere. (cherry picked from commit de0175d)
…8b4a64b6bce360c128 Backport [lldb/Test] Introduce "assertSuccess"
This patch fixes a crash that is happening because of a null pointer dereference in SBFrame. StackFrame::GetRegisterContext says explicitly that you might not get a valid RegisterContext back but the pointer wasn't tested before, resulting in crashes. This should solve the issue. rdar://54462095 Differential Revision: https://reviews.llvm.org/D83343 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb/api] Add checks for StackFrame::GetRegisterContext calls (NFC)
Summary: When tabbing to complete LLDB commands in REPL, characters would at best be missing but at worst cause the REPL to crash due to out of range string access. This patch appends the command character to the completion results to fulfill the assumption that all matches are prefixed by the request's cursor argument prefix. Bug report for the Swift REPL https://bugs.swift.org/browse/SR-12867 Reviewers: teemperor Reviewed By: teemperor Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D82835 (cherry picked from commit 3faec83)
…378da8c8fb4abbdb11 Cherry-pick [lldb] Fix missing characters when autocompleting LLDB commands in REPL
This fixes https://bugs.llvm.org/show_bug.cgi?id=46605. rdar://problem/65158878 Differential Revision: https://reviews.llvm.org/D83317 (cherry picked from commit 0402705)
This is an NFC cleanup for Clang, and a bugfix for the Swift branch. In swift-lldb one target may have multiple scratch TypeSystems, so it is important to pick the one that belongs to the current frame, rather than the one for the current target. <rdar://problem/65001402> (cherry picked from commit 3728133)
[Sema] Teach -Wcast-align to compute alignment of CXXThisExpr
Unify the ExecutionContextScope computation in Materializer.
This patch fixes debugserver incorrectly returning the SDK version instead of the minimum deployment target version. rdar://problem/65001691 Differential Revision: https://reviews.llvm.org/D83443 (cherry picked from commit 15149e4)
of array new expressions with runtime bound. (cherry picked from commit 9a7eda1) # Conflicts: # clang/test/SemaCXX/constant-expression-cxx2a.cpp
Fix debugserver reporting of deployment target
Summary: DWARF-parsing methods in SymbolFileDWARF which update module state typically take the module lock. ParseCallEdgesInFunction doesn't do this, but higher-level locking within lldb::Function (which owns the storage for parsed call edges) is necessary. The lack of locking could explain some as-of-yet unreproducible crashes which occur in Function::GetTailCallingEdges(). In these crashes, the `m_call_edges` vector is non-empty but contains a nullptr, which shouldn't be possible. (If this vector is non-empty, it _must_ contain a non-null unique_ptr.) This may address rdar://55622443 and rdar://65119458. Reviewers: jasonmolenda, friss, jingham Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83359 (cherry picked from commit 6cfc90b)
This assert was failing: assert(CAT && "unexpected type for array initializer"); until this patch landed: 9a7eda1 PR45350: Handle unsized array CXXConstructExprs in constant evaluation
PR45350: Handle unsized array CXXConstructExprs in constant evaluation
…64520e790bf38f30b0 [lldb] Make TestIOHandlerResizeNoEditline pass with Python 2
[Function] Lock the function when parsing call site info
This was happening because the BLR didn't have a use of the X0 arg register, which would end up being re-used in high reg pressure situations. The change also avoids hard coding the use of X0 for the sequence except to copy the value for the call. ld64 should still be able to optimize it. rdar://65438258
|
This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
No description provided.