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

petrhosek · 2019-03-11T07:02:56Z

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 · 2019-03-11T07:03:06Z

r? @nikomatsakis

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

rust-highfive · 2019-03-11T07:03:07Z

⚠️ Warning ⚠️

These commits modify submodules.

rust-highfive · 2019-03-11T07:18:45Z

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)

fbstj · 2019-03-11T07:47:29Z

.gitmodules

@@ -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"]


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

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

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 · 2019-03-11T18:46:23Z

r? @alexcrichton

cramertj · 2019-03-11T19:01:22Z

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 · 2019-03-11T19:03:10Z

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 · 2019-03-12T17:03:24Z

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 · 2019-03-12T17:29:41Z

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 · 2019-03-12T17:48:06Z

@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 · 2019-03-12T19:30:34Z

@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 · 2019-03-12T19:36:15Z

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 · 2019-03-16T17:58:06Z

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

alexcrichton · 2019-03-18T14:45:16Z

@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 · 2019-03-19T17:01:17Z

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 · 2019-03-27T08:51:52Z

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

bors · 2019-03-30T06:11:40Z

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

petrhosek · 2019-04-02T18:36:30Z

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

rust-highfive · 2019-04-02T18:37:41Z

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 · 2019-04-02T18:57:49Z

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 · 2019-04-02T18:57:50Z

✌️ @petrhosek can now approve this pull request

petrhosek · 2019-04-03T01:34:33Z

@bors r+

bors · 2019-04-03T01:34:34Z

📌 Commit 6c0c9a00f9d4ee7c7c136bddf9b5a9f76b4acee5 has been approved by petrhosek

bors · 2019-04-03T14:23:08Z

🔒 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:

git checkout llvm-unwind (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
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.

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 · 2019-04-03T18:29:42Z

@bors r+

bors · 2019-04-03T18:29:43Z

📌 Commit 86d1678 has been approved by petrhosek

tesuji · 2019-04-03T18:54:08Z

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

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 · 2019-04-04T05:25:02Z

⌛ Testing commit 86d1678 with merge f717b58...

bors · 2019-04-04T08:26:12Z

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

jethrogb · 2020-04-17T08:37:10Z

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

petrhosek · 2020-06-11T19:31:17Z

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.

rust-highfive assigned nikomatsakis Mar 11, 2019

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

fbstj reviewed Mar 11, 2019

View reviewed changes

rust-highfive assigned alexcrichton and unassigned nikomatsakis Mar 11, 2019

petrhosek mentioned this pull request Mar 13, 2019

Libunwind cherry pick rust-lang/llvm-project#10

Merged

petrhosek force-pushed the llvm-unwind branch from fdf2fda to 4ed9884 Compare March 13, 2019 18:59

petrhosek force-pushed the llvm-unwind branch from 4ed9884 to cbda99f Compare March 28, 2019 03:01

petrhosek force-pushed the llvm-unwind branch from cbda99f to f59660e Compare April 2, 2019 18:33

petrhosek force-pushed the llvm-unwind branch from f59660e to 6c0c9a0 Compare April 2, 2019 21:33

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 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

Support using LLVM's libunwind as the unwinder implementation

86d1678

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 force-pushed the llvm-unwind branch from 6c0c9a0 to 86d1678 Compare April 3, 2019 18:21

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

bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 4, 2019

bors merged commit 86d1678 into rust-lang:master Apr 4, 2019

This was referenced Apr 4, 2019

std: Upgrade compiler_builtins to fix wasi linkage #59643

Merged

Rollup of 7 pull requests #59688

Closed

jethrogb mentioned this pull request Jun 3, 2020

Make libunwind build hermetic #72746

Merged

tdaede mentioned this pull request Mar 12, 2021

Allow inclusion in static builds xiph/rav1e#2690

Closed

12101111 mentioned this pull request May 16, 2021

libunwind fix and cleanup #84124

Merged

rufo1 mentioned this pull request Jan 14, 2024

⚠️ **Warning** ⚠️ #119964

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

petrhosek commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

fbstj Mar 11, 2019

IsaacWoods Mar 11, 2019

petrhosek Mar 11, 2019

cramertj commented Mar 11, 2019

cramertj commented Mar 11, 2019

alexcrichton commented Mar 11, 2019

petrhosek commented Mar 12, 2019

mati865 commented Mar 12, 2019

alexcrichton commented Mar 12, 2019

petrhosek commented Mar 12, 2019

alexcrichton commented Mar 12, 2019

bors commented Mar 16, 2019

alexcrichton commented Mar 18, 2019

alexcrichton commented Mar 19, 2019

mati865 commented Mar 27, 2019

bors commented Mar 30, 2019

petrhosek commented Apr 2, 2019

rust-highfive commented Apr 2, 2019

alexcrichton commented Apr 2, 2019

bors commented Apr 2, 2019

petrhosek commented Apr 3, 2019

bors commented Apr 3, 2019

bors commented Apr 3, 2019

petrhosek commented Apr 3, 2019

bors commented Apr 3, 2019

tesuji commented Apr 3, 2019

bors commented Apr 4, 2019

bors commented Apr 4, 2019

jethrogb commented Apr 17, 2020

petrhosek commented Jun 11, 2020

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

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

Conversation

petrhosek commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

rust-highfive commented Mar 11, 2019

fbstj Mar 11, 2019

Choose a reason for hiding this comment

IsaacWoods Mar 11, 2019

Choose a reason for hiding this comment

petrhosek Mar 11, 2019

Choose a reason for hiding this comment

cramertj commented Mar 11, 2019

cramertj commented Mar 11, 2019

alexcrichton commented Mar 11, 2019

petrhosek commented Mar 12, 2019

mati865 commented Mar 12, 2019

alexcrichton commented Mar 12, 2019

petrhosek commented Mar 12, 2019

alexcrichton commented Mar 12, 2019

bors commented Mar 16, 2019

alexcrichton commented Mar 18, 2019

alexcrichton commented Mar 19, 2019

mati865 commented Mar 27, 2019

bors commented Mar 30, 2019

petrhosek commented Apr 2, 2019

rust-highfive commented Apr 2, 2019

alexcrichton commented Apr 2, 2019

bors commented Apr 2, 2019

petrhosek commented Apr 3, 2019

bors commented Apr 3, 2019

bors commented Apr 3, 2019

petrhosek commented Apr 3, 2019

bors commented Apr 3, 2019

tesuji commented Apr 3, 2019

bors commented Apr 4, 2019

bors commented Apr 4, 2019

jethrogb commented Apr 17, 2020

petrhosek commented Jun 11, 2020