This repository has been archived by the owner on Apr 2, 2020. It is now read-only.
Merge from master-next (i.e. upstream) #71
Merged
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
Summary: This patch adds a CMake option LLDB_BUILD_FRAMEWORK, which builds libLLDB as a macOS framework instead of as a *nix shared library. With this patch any LLDB executable that has the INCLUDE_IN_FRAMEWORK option set will be built into the Framework's resources directory, and a symlink to the exeuctable will be placed under the build directory's bin folder. Creating the symlinks allows users to run commands from the build directory without altering the workflow. The framework generated by this patch passes the LLDB test suite, but has not been tested beyond that. It is not expected to be fully ready to ship, but it is a first step. With this patch binaries that are placed inside the framework aren't being properly installed. Fixing that would increase the patch size significantly, so I'd like to do that in a follow-up. Reviewers: zturner, tfiala Subscribers: beanz, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D24749 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282110 91177308-0d34-0410-b5e6-96231b3b80d8
The switch coveres all possible values. If a new one is added in the future the compiler will start warning, providing a notification that the switch needs updating. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282111 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282112 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282117 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282119 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Yacine Belkadi Differential Revision: https://reviews.llvm.org/D12158 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282123 91177308-0d34-0410-b5e6-96231b3b80d8
The method was hard-coded to check only the 0th element of the array. This manifested as NSLog messages behaving incorrectly on macOS. (This is independent of the broken DarwinLog feature). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282128 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: When extracting options for long options (starting with `--`), the use of `MIUtilString::SplitConsiderQuotes` to split all the arguments was being conditioned on the option type to be expected. This was wrong as this caused other options to be parsed incorrectly since it was not taking into account the presence of quotes. Patch by Ed Munoz <edmunoz@microsoft.com> Reviewers: edmunoz, ki.stfu Subscribers: ki.stfu, lldb-commits Projects: #lldb Differential Revision: https://reviews.llvm.org/D24202 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282135 91177308-0d34-0410-b5e6-96231b3b80d8
The test exposed a bug in the StructuredData Serialization code, which did not escape the backslash properly. This manifested itself as windows breakpoint serialization roundtrip test not succeeding (as windows paths included backslashes). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282167 91177308-0d34-0410-b5e6-96231b3b80d8
Also fixed up a couple misbehaving functions. It is perfectly legal to have env vars with no values (i.e. the '=' and following need not be present). git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282171 91177308-0d34-0410-b5e6-96231b3b80d8
This started failing recently:
TestDarwinLogSourceDebug.py
It looks like the behavior of specifying the OS_ACTIVITY_MODE
env var with no value used to work for no-info/no-debug content.
That doesn't appear to be the case now. Switch to specifying
the proper value ('default') when no info-level and no debug-level
content is expected.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282172 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282178 91177308-0d34-0410-b5e6-96231b3b80d8
…t build elsewhere too git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282179 91177308-0d34-0410-b5e6-96231b3b80d8
This change is very mechanical. All it does is change the signature of `Options::GetDefinitions()` and `OptionGroup:: GetDefinitions()` to return an `ArrayRef<OptionDefinition>` instead of a `const OptionDefinition *`. In the case of the former, it deletes the sentinel entry from every table, and in the case of the latter, it removes the `GetNumDefinitions()` method from the interface. These are no longer necessary as `ArrayRef` carries its own length. In the former case, iteration was done by using a sentinel entry, so there was no knowledge of length. Because of this the individual option tables were allowed to be defined below the corresponding class (after all, only a pointer was needed). Now, however, the length must be known at compile time to construct the `ArrayRef`, and as a result it is necessary to move every option table before its corresponding class. This results in this CL looking very big, but in terms of substance there is not much here. Differential revision: https://reviews.llvm.org/D24834 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282188 91177308-0d34-0410-b5e6-96231b3b80d8
It doesn't like the implicit conversion from T[] to ArrayRef<T> so I'm using `llvm::makeArrayRef()`. Hopefully I got everything. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282195 91177308-0d34-0410-b5e6-96231b3b80d8
This code was adding an explicit dependency on libclang because lldb needs clang headers, changing this to instead depend on the clang tablegen targets means we don't have to depend on building the clang bits in libclang that lldb doesn't need. Note this is still a bit of a hack because we're adding the dependency to all lldb libraries, instead of just the ones that need it. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282196 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282205 91177308-0d34-0410-b5e6-96231b3b80d8
Also tests for this and the ThreadSpec serialization. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282207 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282212 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282226 91177308-0d34-0410-b5e6-96231b3b80d8
…esponse Switch all callers to use the StringRef version. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282236 91177308-0d34-0410-b5e6-96231b3b80d8
…t test differential review: https://reviews.llvm.org/D24850 reviewers: clayborg, labath git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282258 91177308-0d34-0410-b5e6-96231b3b80d8
Then deal with all the fallout. Differential Revision: https://reviews.llvm.org/D24847 git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282265 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282269 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282270 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282271 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282277 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@282297 91177308-0d34-0410-b5e6-96231b3b80d8
not and FileCheck targets may not be defined in standalone builds. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@284854 91177308-0d34-0410-b5e6-96231b3b80d8 (cherry picked from commit 7bdec51)
This change fixes the linkage issue. We need to get the GitHub CMake setup to populate the CLANG_USED_LIBS instead of using CLANG_ALL_LIBS.
Marked tests will get bug track numbers in final merge.
This test was xfailed while testing the merge from upstream. The merge from master into master-next had the fix for this. (The breakage came in when swift/master-next was updated from swift/master).
Tracked by: rdar://28983120 rdar://28983234
This improves the debugging experience of lldb on Linux.
LLDB_EXPORT_ALL_SYMBOLS used to export everything in liblldb. Now it only exports the standard exported symbols (i.e. the public API symbols) PLUS the lldb_private namespace symbols. This is a preliminary version of the change I have up for review here: https://reviews.llvm.org/D26093 Fixes: llvm.org/pr30822
…is resolved" This reverts commit daa19f2.
This reverts commit 8d36a3f. This test is still failing on CI in the GitHub master-next branch.
This is a final pre-merge prior to pulling master-next into master.
This change depends on the following llvm commit: r282822 (a.k.a. 449cdb5ad51c7720c9f5eecdcb1d142044f16721) This reverts commit fcafba5.
Swift in the master-next branch has access to the utf* functions that have been wrapped in the llvm:: namespace. We don't have that set of changes in swift-llvm/swift-3.1-branch (or swift-llvm/stable) yet. This change removes the llvm:: namespace in a Swift-specific file.
…o APIs (NFC)" This needs to be reverted until swift-llvm/stable catches up with swift-llvm/stable-next. This reverts commit 58bff4a.
lldb-mi somehow lost its dependency on zlib in build-script-driven builds on macOS.
|
Please test with following pull request: @swift-ci Please test |
|
This build, like master-next, has some issues with Linux register handling. I'm filing bugs for those so we can start looking into them. |
|
So far I cannot reproduce the Ubuntu register failures on Ubuntu 14.04 x86_64 with clang-3.6. I'm building locally on a few different Ubuntu versions to see if I can figure out what's up. |
|
I'm also not seeing it on Ubuntu 15.10 x86_64 with clang-3.6. I am running the build with: I'm starting to suspect the issue is related to some deviation between build-swift-cmake.py (which just wraps swift/utils/build-script) and the build-script flags that the CI is using. I am going to retry reproducing this using identical build commands. |
|
The lined used by the CI is: and additionally contains swift-compiler-rt (as compiler-rt). I've made those adjustments and I'm seeing what this yields on Ubuntu 14.04 x86_64 (which happens to be what the PR-testing CI is currently using). |
|
Well, I have converted to using compiler-rt and building with the line quoted in my previous comment on Ubuntu 14.04 x86_64. I am still not reproducing this issue. |
|
At this point I have built 4 different configurations and have not seen this occur on a clean build. I am going to commit this change so I can see what it does with the standard (non-PR) CI. |
tfiala
added a commit
that referenced
this pull request
Nov 3, 2016
(i.e. reapply the merge now that the requisite swift-llvm change has gone into the swift-llvm/stable branch.) This reverts commit 6804137.
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.
@swift-ci please test