Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

vadimcn · 2015-10-20T02:00:07Z

Note: for now, this change only affects -windows-gnu builds.

So why was this libgcc dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's crtbegin.o and crtend.o, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked).

Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine.

Unfortunately, GCC startup objects are built under assumption that libgcc is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go crtbegin/crtend, in come rsbegin/rsend!

A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using gcc as the linker driver and just invoke ld directly.

Rather than injecting a local `_Unwind_Resume` into the current translation unit, just replace `resume` instruction with a direct call the the `eh_unwind_resume` lang item. This is likely to be more robust in the face of future LLVM changes, and also allows us to delegate work back to libgcc's `_Unwind_Resume`.

…our own (for now on for -windows-gnu target only). Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory. Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.

rust-highfive · 2015-10-20T02:00:16Z

r? @arielb1

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

vadimcn · 2015-10-20T02:11:57Z

r? @alexcrichton

alexcrichton · 2015-10-20T03:09:12Z

@vadimcn you never cease to amaze me, fantastic work!

I'll try to get around to this tomorrow, and you may be met with a barrage of questions :)

retep998 · 2015-10-20T15:33:16Z

src/librustc_back/target/windows_base.rs

+            "rsbegin.o".to_string(),
+        ),
+        late_link_args: vec!(
+            "-lmingwex".to_string(),


Just wondering, what do we rely on mingwex for anyway?

reverted changes in configure, refactored target.mk

vadimcn · 2015-10-21T21:16:30Z

Looks better?

alexcrichton · 2015-10-21T23:22:17Z

src/rtstartup/rsbegin.rs

+    #[no_mangle]
+    #[link_section = ".eh_frame"]
+    // Marks beginning of the stack frame unwind info section
+    pub static __EH_FRAME_BEGIN__: [u8; 0] = [];


So just to clarify, this works because:

The linker will construct the .eh_frame section from the list of items contained within it on the command line. This is, however, guarantee to be the first, so &__EH_FRAME_BEGIN__ is guaranteed to be a pointer to the start of the section.

Similarly, rsend.o is guarnateed to be at the end, so it's guaranteed that &__EH_FRAME_END__ is at the end of the section.

Does that sound right? Also out of curiosity, what is the __EH_FRAME_END__ symbol used for? It's not explicitly referenced here, so is it referenced or dynamically loaded from the CRT or elsewhere?

Yes, that's my understanding of how this works.

Also out of curiosity, what is the EH_FRAME_END symbol used for?

It's used to support the weight of eh_frame section, thus the extra wide base.

Hm ok, and by "weight" and "extra wide base" do you mean how __EH_FRAME_END__ is a u32 while the start is a [u8; 0]? (a fact I just realized)

...the other reason is that you can't have a static variable (the zero footer) without a name (at least that I know of).

By extra wide base I meant the underscores :) just kidding :)

Oh dear it looks like my ignorance is leaking, a zero footer makes sense to me!

alexcrichton · 2015-10-23T05:09:37Z

cc @brson, just wanna give you a heads up about the we-are-building-our-own-object-files strategy. It seems fine to me but figured you may want to know!

alexcrichton · 2015-10-24T18:36:34Z

This is basically r+ from me, but I think I'd prefer to hold this off until after the 1.5 beta is released so this lands in 1.6 instead (just so we have some extra time to weed out any problems here). Does that sound ok?

vadimcn · 2015-10-25T00:42:54Z

That's next Thursday, right? Fine by me.

alexcrichton · 2015-10-25T17:33:31Z

OK cool, now I just wish I could bors r+ date=2015-...

alexcrichton · 2015-10-28T21:23:41Z

@bors: r+ afc3046

bors · 2015-10-28T21:28:32Z

⌛ Testing commit afc3046 with merge ccc9ff2...

bors · 2015-10-28T21:37:40Z

💔 Test failed - auto-win-gnu-64-opt

vadimcn · 2015-10-29T23:16:22Z

Uh-oh, that's a stage0 ICE. Crashes in llvm::AttributeSet::removeAttributes

vadimcn · 2015-11-01T02:01:20Z

Looks like this was my own fault. The tricks I played with injection of the _Unwind_Resume symbol somehow caused it to turn into a "constant expression" value (but only on x86_64, which doesn't even use this symbol ), which did not sit well with LLVM functions like LLVMRemoveAttribute. Hiding it from stage0 resolves the issue.
r? @alexcrichton

alexcrichton · 2015-11-01T17:15:28Z

@bors: r+ 0332ee9

bors · 2015-11-01T17:15:31Z

⌛ Testing commit 0332ee9 with merge 7140918...

Note: for now, this change only affects `-windows-gnu` builds. So why was this `libgcc` dylib dependency needed in the first place? The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process. The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process. All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output). Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process. This pretty much means that the unwinder must be in a shared library (unless everything is statically linked). Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once. So if we link the unwinder statically to one of Rust's crates, everything should be fine. Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them. So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`! A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.

bors · 2015-11-01T20:00:05Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

vadimcn added 6 commits October 18, 2015 19:57

Implement eh_unwind_resume in libstd.

def917a

Create entry points for unwind frame registry in libstd.

c807ff3

Fix up tests and docs.

adce670

Use cfg_attr for switching link attrs in libunwind.

145b843

rust-highfive assigned arielb1 Oct 20, 2015

rust-highfive assigned alexcrichton and unassigned arielb1 Oct 20, 2015

retep998 reviewed Oct 20, 2015
View reviewed changes

vadimcn added 2 commits October 21, 2015 10:05

Use gcc -print-file-name for finding C runtime startup objects:

9a71c5c

reverted changes in configure, refactored target.mk

Moar comments.

d710f8b

alexcrichton reviewed Oct 21, 2015
View reviewed changes

Drop advapi32 and shell32 from late_link_args.

afc3046

Fix stage0 ICE caused by the old _Unwind_Resume override trickery.

0332ee9

bors merged commit 0332ee9 into rust-lang:master Nov 1, 2015

alexcrichton mentioned this pull request Nov 5, 2015

Build failure with MinGW-w64 gcc 5.2.0 #29649

Closed

Mark-Simulacrum mentioned this pull request Jan 27, 2020

Optimize catch_unwind to match C++ try/catch #67502

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

vadimcn commented Oct 20, 2015

rust-highfive commented Oct 20, 2015

vadimcn commented Oct 20, 2015

alexcrichton commented Oct 20, 2015

retep998 Oct 20, 2015

vadimcn commented Oct 21, 2015

alexcrichton Oct 21, 2015

vadimcn Oct 21, 2015

alexcrichton Oct 21, 2015

vadimcn Oct 21, 2015

vadimcn Oct 21, 2015

alexcrichton Oct 21, 2015

alexcrichton commented Oct 23, 2015

alexcrichton commented Oct 24, 2015

vadimcn commented Oct 25, 2015

alexcrichton commented Oct 25, 2015

alexcrichton commented Oct 28, 2015

bors commented Oct 28, 2015

bors commented Oct 28, 2015

vadimcn commented Oct 29, 2015

vadimcn commented Nov 1, 2015

alexcrichton commented Nov 1, 2015

bors commented Nov 1, 2015

bors commented Nov 1, 2015

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

Conversation

vadimcn commented Oct 20, 2015

rust-highfive commented Oct 20, 2015

vadimcn commented Oct 20, 2015

alexcrichton commented Oct 20, 2015

retep998 Oct 20, 2015

Choose a reason for hiding this comment

vadimcn commented Oct 21, 2015

alexcrichton Oct 21, 2015

Choose a reason for hiding this comment

vadimcn Oct 21, 2015

Choose a reason for hiding this comment

alexcrichton Oct 21, 2015

Choose a reason for hiding this comment

vadimcn Oct 21, 2015

Choose a reason for hiding this comment

vadimcn Oct 21, 2015

Choose a reason for hiding this comment

alexcrichton Oct 21, 2015

Choose a reason for hiding this comment

alexcrichton commented Oct 23, 2015

alexcrichton commented Oct 24, 2015

vadimcn commented Oct 25, 2015

alexcrichton commented Oct 25, 2015

alexcrichton commented Oct 28, 2015

bors commented Oct 28, 2015

bors commented Oct 28, 2015

vadimcn commented Oct 29, 2015

vadimcn commented Nov 1, 2015

alexcrichton commented Nov 1, 2015

bors commented Nov 1, 2015

bors commented Nov 1, 2015