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.

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

Don't eliminate frame pointers on thumb targets #69248

Merged
merged 2 commits into from Feb 19, 2020

Conversation

@jonas-schievink
Copy link
Member

jonas-schievink commented Feb 17, 2020

This should hopefully fix issues #69231 and rust-embedded/cortex-m-rt#139.

I couldn't test this locally as the rustc I produced does not create binaries (no idea why). Resolved.

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Feb 17, 2020

r? @estebank

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

@jonas-schievink

This comment has been minimized.

Copy link
Member Author

jonas-schievink commented Feb 17, 2020

@hanna-kruppe

This comment has been minimized.

Copy link
Member

hanna-kruppe commented Feb 17, 2020

LGTM (modulo nit), but I'm not 100% sure about signing off such a change to a target (family) that I don't really use or know. Can we get a second opinion from someone versed in the targets this affects? I suppose I could also rubber-stamp and we'll see if anyone complains about their program becoming more bloated.

@jonas-schievink

This comment has been minimized.

Copy link
Member Author

jonas-schievink commented Feb 17, 2020

As it stands, this will only apply to the microcontroller targets, not the other thumb targets (which are thumbv7a_pc_windows_msvc, and thumbv7 linux/android targets), so the impact should at least be limited to embedded apps only. We do care about program sizes there, of course, but I think this is a worthwhile tradeoff to make, especially since users can still override it.

Can we get a second opinion from someone versed in the targets this affects?

I mentioned the this fix to @japaric at work, who I believe added these targets originally, so perhaps I can r? @japaric

@japaric

This comment has been minimized.

Copy link
Member

japaric commented Feb 18, 2020

I checked the output machine code of libcore.rlib and the change makes what we want. diff below:

 00000000 <core::panicking::panic>:
+        b580            push    {r7, lr}
+        466f            mov     r7, sp
         b088            sub     sp, #32
         4694            mov     ip, r2
         f240 0200       movw    r2, #0

I couldn't test this locally as the rustc I produced does not create binaries (no idea why).

AFAICT, LLD does not produce a final artifact with these changes. If you change the linker to GNU LD then you get an artifact. I haven't tried the GNU LD output on hardware though; I'll try that later today.

@japaric

This comment has been minimized.

Copy link
Member

japaric commented Feb 18, 2020

AFAICT, LLD does not produce a final artifact with these changes.

Scratch that. I had a rust-lld binary in my .cargo/bin directory and that was eliminating the final artifact somehow. rustc -C linker=/path/to/rustup/toolchain/nightly/rust-lld (..) does produce an artifact.

@MabezDev

This comment has been minimized.

Copy link

MabezDev commented Feb 18, 2020

Just to make sure, I built and ran the test case with noth lld & GNU ld and both produced debuggable binaries with the correct backstrace.

@jonas-schievink

This comment has been minimized.

Copy link
Member Author

jonas-schievink commented Feb 18, 2020

Nice!

@japaric

This comment has been minimized.

Copy link
Member

japaric commented Feb 18, 2020

I can also confirm that, with these changes (and rust-lld), (virtual) unwinding / backtraces work with a custom tool I wrote.

The missing artifact issue that @jonas-schievink and I observed was just a few bugs in other tools (e.g. cargo-binutils). Those have been already reported elsewhere.

This looks good to me and fixes a huge pain point for people that are using backtraces in GDB. Thanks @jonas-schievink and @MabezDev (who I believe first found out about the frame-pointer option in rustc / llvm) for working on this!

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Feb 18, 2020

📌 Commit 27cfb2b has been approved by japaric

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Feb 19, 2020
Don't eliminate frame pointers on thumb targets

This should hopefully fix issues rust-lang#69231 and rust-embedded/cortex-m-rt#139.

~~I couldn't test this locally as the rustc I produced does not create binaries (no idea why).~~ Resolved.
bors added a commit that referenced this pull request Feb 19, 2020
Rollup of 5 pull requests

Successful merges:

 - #68863 (ci: switch macOS builders to 10.15)
 - #69142 (Add shared script for linkchecking books.)
 - #69248 (Don't eliminate frame pointers on thumb targets)
 - #69280 (Remove special case for `simd_shuffle` arg promotion)
 - #69284 (Reword OpenOptions::{create, create_new} doc.)

Failed merges:

r? @ghost
@bors bors merged commit c6ad1e2 into rust-lang:master Feb 19, 2020
4 checks passed
4 checks passed
pr Build #20200217.61 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-7) Linux x86_64-gnu-llvm-7 succeeded
Details
pr (Linux x86_64-gnu-tools) Linux x86_64-gnu-tools succeeded
Details
@jonas-schievink jonas-schievink deleted the jonas-schievink:thumb-fp branch Feb 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

7 participants
You can’t perform that action at this time.