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

Unwinding on mac64 is broken with fp elim #11954

Closed
alexcrichton opened this issue Jan 31, 2014 · 5 comments
Closed

Unwinding on mac64 is broken with fp elim #11954

alexcrichton opened this issue Jan 31, 2014 · 5 comments
Labels
A-codegen Area: Code generation I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@alexcrichton
Copy link
Member

We recently turned on frame pointer elimination in our LLVM codegen. This is apparently causing many problems with unwinding on mac64 platforms. This isn't quite deterministic, but some patches trigger this regularly.

For now, I'm adding an exception for mac64 platforms.
@alexcrichton alexcrichton mentioned this issue Jan 31, 2014
Merged
alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 31, 2014
@alexcrichton
Disable fp elim on mac64
e8e0cdd 
I believe that this is leading to lots of failures on the bots.

cc rust-lang#11954
bors added a commit that referenced this issue Jan 31, 2014
@bors
auto merge of #11955 : alexcrichton/rust/fix-unwinding-on-mac-64, r=cmr
f478796 
I believe that this is leading to lots of failures on the bots.

cc #11954
@reem
Copy link
Contributor

reem commented Aug 8, 2014

Triage: Is this still an issue? Do we want/need frame point elimination on OS X? If not or there is already a satisfactory fix this should be closed.

@alexcrichton
Copy link
Member Author

Yes, in theory there is a bit of a codegen/perf improvement if we have fp elimination, but it's still disabled for mac

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

@alexcrichton what about now? I can't find that code you linked to anymore, it would seem that src/librustc_back/target/apple_base.rs (which I think is the new version) mentions nothing about this.

@alexcrichton
Copy link
Member Author

Ah it just moved over here (still disabled)

@steveklabnik
Copy link
Member

Triage: no longer disabled https://github.com/rust-lang/rust/blob/691eba1358fc3c9c7a8033314a4112d43680c128/src/librustc_back/target/i686_apple_darwin.rs

@alexcrichton alexcrichton mentioned this issue Jul 20, 2020
Merged
shepmaster added a commit to shepmaster/rust that referenced this issue Jul 21, 2020
@shepmaster
Allow eliminating the frame pointer on x86_64-apple-darwin
12712f1 
Quoting @alexcrichton:

> the fp elim here comes from the code contents of the patch:
>
> ```rust
>     // FIXME: rust-lang#11906: Omitting frame pointers breaks retrieving the value of a parameter.
>     // FIXME: rust-lang#11954: mac64 unwinding may not work with fp elim
>     let no_fp_elim = (sess.opts.debuginfo != NoDebugInfo) ||
>                      (sess.targ_cfg.os == abi::OsMacos &&
>                       sess.targ_cfg.arch == abi::X86_64);
> ```
>
>
> which points to rust-lang#11954 which
> I believe was [incorrectly closed][] (only references i686, not
> x86_64).
>
> This sounds vaguely familiar about how it's related to
> unwinding. This also is the definition of something lost to time
> which we unfortunately lost track of :(.
>
> [incorrectly closed]: rust-lang#11954 (comment)
@shepmaster shepmaster mentioned this issue Jul 21, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation 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
4 participants
@steveklabnik @alexcrichton @thestinger @reem