Disable all unwinding on -Z no-landing-pads LTO

[alexcrichton]

When performing LTO, the rust compiler has an opportunity to completely strip
all landing pads in all dependent libraries. I've modified the LTO pass to
recognize the -Z no-landing-pads option when also running an LTO pass to flag
everything in LLVM as nothrow. I've verified that this prevents any and all
invoke instructions from being emitted.

I believe that this is one of our best options for moving forward with
accomodating use-cases where unwinding doesn't really make sense. This will
allow libraries to be built with landing pads by default but allow usage of them
in contexts where landing pads aren't necessary.

[alexcrichton]

I think there's a few things that should be reviewed about this:

• whether the code is good (as usual)
• whether this should be a crate attribute or a compile-time flag (I don't think this should be allowed as a crate attribute on rlib or dylib outputs)
• whether this should actually close the issue in question

[huonw]

How will this interact with --test (especially as a crate attribute, since there is no way to conditionally add/remove individual attributes from items (and, in fact, no way at all for crate attributes))?

[thestinger]

@alexcrichton: I'm not quite sure it should close it, because it would be nice to be able to omit them without optimizations enabled or without link-time optimization. This should also probably not work if unwinding is used because it's going to be undefined behaviour. One way to do that would be having an abort language item in addition to fail, and enforcing that only one or the other it undefined. It's still up to the user to get it right, but it will prevent problems with the default standard library configuration.

[alexcrichton]

I don't think that we should encourage distribution of libraries with -Z no-landing-pads because most rust programs cannot safely link to them. I am very much in favor of this solution because the landing-pad-presence is a choice of the final-downstream user. It's a little unfortunate that this can only be done at LTO time, but that's also the only time at which we can alter upstream code.

I agree that the only way to truly safely do this is to statically ensure that fail! does not unwind and rather aborts. Right now we have no compile-time checking that the failure function triggers an abort rather than failing. I am a firm believer in that crates should be compiled once, so I should never have to make a decision of calling fail!() vs abort!().

The best way that I can think of doing something like this:

• If landing pads are generated, then the compiler will link dylibs/binaries to librustunwind which defines two symbols: rust_try and rust_begin_unwind. The compiler will also manually specify -lstdc++ on the link line. Note that this is different than what happens today in that libstd currently specifies the libstdc++ dependency via std::rtdeps. Additionally, librustunwind is currently an object file inside librustrt
• If landing pads are not generated, then the compiler will instead link to librustnounwind. This library would also define two symbols: rust_try and rust_begin_unwind but the difference would be that rust_begin_unwind just aborts and rust_try just calls the function. The compiler would then have no need to link against libstdc++

If we did something like this, then we would have a static guarantee that code compiled with -Z no-landing-pads would not unwind through the fail!() macro (because no support for it was ever linked in). Additionally, this means that even libstd doesn't have to get recompiled with and without unwinding.

As another consequence of possibly going down this route, if we start making no-landing-pads a first-class option, I would want to make it a crate attribute and have it be a compiler error if an rlib or dylib is being generated. We could explore a method of allowing no-landing-pads for dylib outputs, but this has the same problems of mixing static/dynamic linking in that all upstream dependencies must be tracked.

[pcwalton]

I like this approach because it handles the kernel case quite nicely (as kernels definitely want LTO and probably don't want unwinding). Although if your kernel supports loadable kernel modules then, well, we'll have to come up with something.

[alexcrichton]

(I force pushed to remove the 'Closes' part of the commit message)