Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support using LLVM's libunwind as the unwinder implementation #59089

Merged
merged 1 commit into from
Apr 4, 2019

Conversation

petrhosek
Copy link
Contributor

This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.

@rust-highfive
Copy link
Collaborator

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 11, 2019
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:2060500d:start=1552287844715727058,finish=1552287846353950989,duration=1638223931
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:00:00] Submodule 'src/doc/embedded-book' (https://github.com/rust-embedded/book.git) registered for path 'src/doc/embedded-book'
[00:00:00] Submodule 'src/doc/nomicon' (https://github.com/rust-lang-nursery/nomicon.git) registered for path 'src/doc/nomicon'
[00:00:00] Submodule 'src/doc/reference' (https://github.com/rust-lang-nursery/reference.git) registered for path 'src/doc/reference'
[00:00:00] Submodule 'src/doc/rustc-guide' (https://github.com/rust-lang/rustc-guide.git) registered for path 'src/doc/rustc-guide'
[00:00:00] Submodule 'src/libunwind/libunwind' (https://git.llvm.org/git/libunwind.git) registered for path 'src/libunwind/libunwind'
[00:00:00] Submodule 'src/tools/cargo' (https://github.com/rust-lang/cargo.git) registered for path 'src/tools/cargo'
[00:00:00] Submodule 'src/tools/clippy' (https://github.com/rust-lang-nursery/rust-clippy.git) registered for path 'src/tools/clippy'
[00:00:00] Submodule 'src/tools/miri' (https://github.com/rust-lang/miri.git) registered for path 'src/tools/miri'
[00:00:00] Submodule 'src/tools/rls' (https://github.com/rust-lang-nursery/rls.git) registered for path 'src/tools/rls'
---

[00:03:59] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/docs/conf.py:251: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:111: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:122: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:124: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:125: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:127: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:131: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:236: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:237: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:240: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:243: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:245: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:246: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:247: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:254: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:256: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:258: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:259: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:261: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:265: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:310: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:312: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:314: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:318: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:323: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:340: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:341: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:342: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:343: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:347: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:348: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:352: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:375: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:376: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:379: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:382: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:383: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:387: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:390: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:391: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:405: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:427: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:428: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/config.h:69: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:479: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:481: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:483: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:492: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:494: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:496: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:79: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:116: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:120: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:129: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:712: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/test/libunwind/test/__init__.py: empty file
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/test/libunwind/__init__.py: empty file
[00:04:01] some tidy checks failed
[00:04:01] 
[00:04:01] 
[00:04:01] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:01] 
[00:04:01] 
[00:04:01] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:01] Build completed unsuccessfully in 0:00:43
[00:04:01] Build completed unsuccessfully in 0:00:43
[00:04:01] make: *** [tidy] Error 1
[00:04:01] Makefile:68: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1c4c1b0a
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Mon Mar 11 07:08:19 UTC 2019
---
travis_time:end:0cde8db0:start=1552288100375095301,finish=1552288100380276874,duration=5181573
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0564bd60
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:00f918c3
travis_time:start:00f918c3
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:018f50bb
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

.gitmodules Outdated
@@ -47,3 +47,6 @@
[submodule "src/doc/embedded-book"]
path = src/doc/embedded-book
url = https://github.com/rust-embedded/book.git
[submodule "src/libunwind/libunwind"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be the libunwind from the LLVM monorepo?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially since we already have a llvm-project submodule with a copy of libunwind in tree, that would be better imo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine switching to llvm-project, but that version is behind upstream and is missing some important changes to libunwind that removed the C++ standard library dependency. We need to roll it first.

@cramertj
Copy link
Member

r? @alexcrichton

@cramertj
Copy link
Member

Looks like the travis failures are coming from tidy errors in src/libunwind/libunwind. I believe that directory will have to be added to this list.

@alexcrichton
Copy link
Member

Thanks for this @petrhosek! I had no idea it was so easy to pull this in :)

To get an idea, are y'all thinking of turning this on by default for Fuchsia? Additionally, do you know if there are other targets which may wish to turn this on by default? Turning this on by default seems like a tantalizing proposition at this point, but we probably can't take a dependency on a C++ compiler just yet and we'd also want to give this some time to bake.

In terms of llvm-project and such, when you say upstream to you mean rust-lang's fork of the llvm-project repo? If that's all that's necessary to update I think we'll want to go ahead and pull the necessary patches into our fork and then use the src/llvm-project directory. If it's a case of LLVM's own monorepo vs the sub-repos they have then this seems like a fine temporary holdover.

I'm also somewhat surprised that there's no source level changes here, even for platforms like MSVC. This seems to have build logic for MSVC/Linux/macOS, but I was wondering if you'd tested it there as well? MSVC for example I thought we only used kernel32.dll things rather than a linked in unwinder.

@petrhosek
Copy link
Contributor Author

Thanks for this @petrhosek! I had no idea it was so easy to pull this in :)

To get an idea, are y'all thinking of turning this on by default for Fuchsia? Additionally, do you know if there are other targets which may wish to turn this on by default?

Yes, we plan to enable this for our Rust toolchain build. This is currently a blocker for deployment in our internal Linux environment since we don't have libgcc_s available there, but we would also like to use it for Fuchsia.

Turning this on by default seems like a tantalizing proposition at this point, but we probably can't take a dependency on a C++ compiler just yet and we'd also want to give this some time to bake.

To clarify, this requires only C++ compiler, not C++ standard library (once we bring in the libuwind changes).

In terms of llvm-project and such, when you say upstream to you mean rust-lang's fork of the llvm-project repo? If that's all that's necessary to update I think we'll want to go ahead and pull the necessary patches into our fork and then use the src/llvm-project directory. If it's a case of LLVM's own monorepo vs the sub-repos they have then this seems like a fine temporary holdover.

Yes, that's what I had in mind. I'd be fine using rust-lang's fork if we can cherry-pick the necessary patches (assuming that's easier than rolling the entire repository forward):

llvm/llvm-project@7fac517
llvm/llvm-project@90bcfaa

I'm also somewhat surprised that there's no source level changes here, even for platforms like MSVC. This seems to have build logic for MSVC/Linux/macOS, but I was wondering if you'd tested it there as well? MSVC for example I thought we only used kernel32.dll things rather than a linked in unwinder.

I haven't tested the change on those platforms yet. It might be safer to restrict this only for Linux and Fuchsia. I'd expect macOS to be safe as well since libunwind is already being used there as the default unwinder. I'm less familiar with the status on Windows.

@mati865
Copy link
Contributor

mati865 commented Mar 12, 2019

I'm less familiar with the status on Windows.

AFAIK Dwarf unwinding doesn't work yet so it cannot be used for i686-pc-windows-gnu (SJIJ works but Dwarf is faster), SEH used by x86_64-pc-windows-gnu is in a good shape.
This commit would need backporting for it to build:
llvm/llvm-project@6ccad0a#diff-2467f5cba1ecc34d53f4480cd654aa55

@alexcrichton
Copy link
Member

@petrhosek ok cool, that all sounds great!

In that case how about:

  • Let's cherry-pick changes to our llvm-project fork. If necessary though we can fast-forward, but that's normally a pretty big hassle.
  • For now this'll be left turned off, but the config changes here look perfect for threading it through.
  • I'd personally prefer to leave only the supported platforms in for now, letting new support be added explicitly and tested as it's added (so probably leaving out the Windows/MSVC/Darwin support for now).

How's that sound?

(and just to confirm, LLVM's libunwind has the same API as the libgcc_s one we expect, so that's why there's no source-level changes necessary on Linux?)

@petrhosek
Copy link
Contributor Author

@petrhosek ok cool, that all sounds great!

In that case how about:

  • Let's cherry-pick changes to our llvm-project fork. If necessary though we can fast-forward, but that's normally a pretty big hassle.

How do you do that? Do I need to send those changes as pull requests to your llvm-project fork or can you or someone else just cherry pick them directly?

  • For now this'll be left turned off, but the config changes here look perfect for threading it through.
  • I'd personally prefer to leave only the supported platforms in for now, letting new support be added explicitly and tested as it's added (so probably leaving out the Windows/MSVC/Darwin support for now).

How's that sound?

SGTM

(and just to confirm, LLVM's libunwind has the same API as the libgcc_s one we expect, so that's why there's no source-level changes necessary on Linux?)

Yes, it's designed to be a drop-in replacement. We're using LLVM's libunwind in our C/C++ toolchain for both Linux and Fuchsia without any problems.

@alexcrichton
Copy link
Member

Oh sorry yeah, a cherry-pick would be doing the cherry-pick locally and then sending a PR to https://github.com/rust-lang/llvm-project/tree/rustc/8.0-2019-01-16. I can merge that and then afterwards the submodule can be updated here

@bors
Copy link
Contributor

bors commented Mar 16, 2019

☔ The latest upstream changes (presumably #59226) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

@petrhosek when rebasing this can you also update the llvm-project submodule to rust-lang/llvm-project@8f80418? I was testing out an experimental change in #58854 on a separate branch, and that PR merged, so I've merged my temporary branch into the master branch of rust-lang/llvm-project which should have both your changes and my changes

@alexcrichton
Copy link
Member

Ah actually in parallel as well we have another submodule update which includes the changes needed for this PR as well as the ones I mentioned previously (JFYI)

@mati865
Copy link
Contributor

mati865 commented Mar 27, 2019

Ping @petrhosek, this PR requires rebase. LLVM submodule has been updated by another PR so it's no longer necessary.

@bors
Copy link
Contributor

bors commented Mar 30, 2019

☔ The latest upstream changes (presumably #59464) made this pull request unmergeable. Please resolve the merge conflicts.

@petrhosek
Copy link
Contributor Author

Ping? Would it be possible to take a look again?

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:09c31340:start=1554230093841327556,finish=1554230096317889139,duration=2476561583
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:02:00] 
######################################################################## 100.0%
[00:02:00] extracting /checkout/obj/build/cache/2019-03-20/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:02:00]     Updating crates.io index
[00:02:15] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:15] Build completed unsuccessfully in 0:00:31
[00:02:15] make: *** [prepare] Error 1
[00:02:15] Makefile:69: recipe for target 'prepare' failed
[00:02:16] Command failed. Attempt 2/5:
[00:02:16] Command failed. Attempt 2/5:
[00:02:16] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:16] Build completed unsuccessfully in 0:00:00
[00:02:16] Makefile:69: recipe for target 'prepare' failed
[00:02:16] make: *** [prepare] Error 1
[00:02:18] Command failed. Attempt 3/5:
[00:02:18] Command failed. Attempt 3/5:
[00:02:19] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:19] Build completed unsuccessfully in 0:00:00
[00:02:19] Makefile:69: recipe for target 'prepare' failed
[00:02:19] make: *** [prepare] Error 1
[00:02:22] Command failed. Attempt 4/5:
[00:02:22] Command failed. Attempt 4/5:
[00:02:22] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:22] Build completed unsuccessfully in 0:00:00
[00:02:22] make: *** [prepare] Error 1
[00:02:22] Makefile:69: recipe for target 'prepare' failed
[00:02:26] Command failed. Attempt 5/5:
[00:02:26] Command failed. Attempt 5/5:
[00:02:26] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:26] Build completed unsuccessfully in 0:00:00
[00:02:27] make: *** [prepare] Error 1
[00:02:27] Makefile:69: recipe for target 'prepare' failed
[00:02:27] The command has failed after 5 attempts.
---
travis_time:end:0a5a4668:start=1554230256764929768,finish=1554230256771327382,duration=6397614
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1c66074c
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:090c841e
travis_time:start:090c841e
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:11d77aa8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@alexcrichton
Copy link
Member

Oops sorry didn't realize this was ready to go again! If you want to run ./x.py build it should regenerate the lock file early on and that should be all that's necessary now!

Otherwise this lgtm, so

@bors: delegate+

@bors
Copy link
Contributor

bors commented Apr 2, 2019

✌️ @petrhosek can now approve this pull request

@petrhosek
Copy link
Contributor Author

@bors r+

@bors
Copy link
Contributor

bors commented Apr 3, 2019

📌 Commit 6c0c9a00f9d4ee7c7c136bddf9b5a9f76b4acee5 has been approved by petrhosek

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 3, 2019
@bors
Copy link
Contributor

bors commented Apr 3, 2019

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout llvm-unwind (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self llvm-unwind --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/bootstrap/lib.rs
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 3, 2019
This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
@petrhosek
Copy link
Contributor Author

@bors r+

@bors
Copy link
Contributor

bors commented Apr 3, 2019

📌 Commit 86d1678 has been approved by petrhosek

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 3, 2019
@tesuji
Copy link
Contributor

tesuji commented Apr 3, 2019

@petrhosek You might want to use bors r=<approver> instead.

bors added a commit that referenced this pull request Apr 4, 2019
Support using LLVM's libunwind as the unwinder implementation

This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.
@bors
Copy link
Contributor

bors commented Apr 4, 2019

⌛ Testing commit 86d1678 with merge f717b58...

@bors
Copy link
Contributor

bors commented Apr 4, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrhosek
Pushing f717b58 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 4, 2019
@bors bors merged commit 86d1678 into rust-lang:master Apr 4, 2019
@jethrogb
Copy link
Contributor

Is there a reason you're not just invoking CMake?

@petrhosek
Copy link
Contributor Author

We could use CMakeLists.txt, the reason I avoided it was to reduce the dependencies, especially since libunwind's build is very minimal.

I'm not sure if it's necessarily going to reduce the need for maintenance. libunwind's CMake build is also evolving, and most new flags are usually gated on options which would need to be reflected here as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.