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.

Sign up for GitHub

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

Jump to bottom

no way to disable exception handling with static/dynamic linking #10780

Closed
thestinger opened this issue Dec 3, 2013 · 3 comments
Closed

no way to disable exception handling with static/dynamic linking #10780

thestinger opened this issue Dec 3, 2013 · 3 comments
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

There's no equivalent to -Z no-landing-pads for static/dynamic libraries. Since it's not possible to mark foreign functions as not throwing like it is with __attribute__((nothrow)), Rust will always output lots of unwinding tables with a Rust-specific unwinding personality/calls. This would be a lot less bad if Rust actually read the C library headers with libclang and dealt with the attributes like nothrow.
@thestinger thestinger mentioned this issue Dec 6, 2013
Closed
@alexcrichton alexcrichton mentioned this issue Dec 11, 2013
Merged
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 11, 2013
@alexcrichton
Disable all unwinding on -Z no-landing-pads LTO
667d114 
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.

cc rust-lang#10780
@thestinger thestinger mentioned this issue Jan 29, 2014
Closed
@brson
Copy link
Contributor

brson commented Jan 30, 2014

Can -Z no-landing-pads work for static and dynamic libraries?

This is similar to #11871 where we have a language feature that has a runtime dependency, but it can't be turned off, and you wouldn't want to accidentally combine crates with the wrong options. Perhaps we can add something to the metadata to record which runtime features were in use, and start adding these options.

@thestinger
Copy link
Contributor Author

I think adding a flag to the metadata is the best idea. It would be really nice to omit the landing pads and invoke calls in the first place too.

@thestinger thestinger added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Sep 19, 2014
@thestinger
Copy link
Contributor Author

Closing in favour of #18511.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@brson @thestinger