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

No support for lto build modes? after 1.67.1 #146

Closed
redbaron opened this issue Mar 6, 2023 · 17 comments · Fixed by #147
Closed

No support for lto build modes? after 1.67.1 #146

redbaron opened this issue Mar 6, 2023 · 17 comments · Fixed by #147

Comments

@redbaron
Copy link

redbaron commented Mar 6, 2023

When I enable lto = "thin" in the release profile cargo asm stops showing assembly output for my binary:

warning: ignoring emit path because multiple .s files were produced
Error: Cannot locate the path to the asm file
@pacak
Copy link
Owner

pacak commented Mar 6, 2023

Is it the most recent version? What platform? Do you have your project available somewhere or can you make a minimal example? Works for me...

@redbaron
Copy link
Author

redbaron commented Mar 6, 2023

I am on latest 1.67.1 stable on ARM64. I'll try to prepare minimal reproducer

@pacak
Copy link
Owner

pacak commented Mar 6, 2023

Is it the most recent version of cargo-show-asm?

@redbaron
Copy link
Author

redbaron commented Mar 6, 2023

yes, latest released 0.2.14

@reisnera
Copy link

reisnera commented Mar 8, 2023

This is happening to me in linux (well, WSL). Latest rust, latest cargo-show-asm. Minimal reproducible example:

  1. Make a new empty project with cargo new
  2. Add to Cargo.toml:
[profile.release]
lto = "thin"
  1. Try to do anything with cargo asm

Edit: I should specify, I got the same error as @redbaron

@pacak
Copy link
Owner

pacak commented Mar 8, 2023

@reisnera this works for me fine on linux. Can you nuke target (cargo clean), run it with cargo asm -vvv and attach the full output here? Also a list of all the files in target would be great.

@reisnera
Copy link

reisnera commented Mar 8, 2023

Sure, see attached flies
output.txt
filelist.txt

@pacak
Copy link
Owner

pacak commented Mar 8, 2023

@reisnera

  • Is it working fine for other rust projects?
  • Do you have incremental compilation enabled by any chance?
  • Can you try clearing CARGO_INCREMENTAL env variable if you have one?

@pacak
Copy link
Owner

pacak commented Mar 8, 2023

This seems to be related rust-lang/cargo#7765

@reisnera
Copy link

reisnera commented Mar 8, 2023

Hey @pacak thanks for the reply. If I don't try to use lto in this new/empty project it works just fine. I tried disabling incremental compilation by setting CARGO_INCREMENTAL=0 and it still doesn't work (I do not have this set to anything normally, which I assume means incremental compilation is enabled by default).

@pacak
Copy link
Owner

pacak commented Mar 9, 2023

Managed to reproduce it locally by upgrading rustc to 1.67.1, was working fine with 1.66.0. Will poke around.

@pacak pacak changed the title No support for lto build modes? No support for lto build modes? after 1.67.1 Mar 9, 2023
@pacak
Copy link
Owner

pacak commented Mar 9, 2023

rust-lang/rust#103610 - caused by this it seems

@pacak
Copy link
Owner

pacak commented Mar 9, 2023

A workaround is to pass -C lto=no or -C lto=fat, need to figure out how to detect if it failed due to lto and try again without it automagically...

@pacak pacak mentioned this issue Mar 9, 2023
@pacak pacak closed this as completed in #147 Mar 9, 2023
@pacak
Copy link
Owner

pacak commented Mar 9, 2023

need to figure out how to detect if it failed due to lto and try again without it automagically...

Actually cargo-show-asm only looks at what rustc generates so lto settings should not affect the results. Always using -Clto=no works. Released 0.2.15.

@reisnera
Copy link

reisnera commented Mar 9, 2023

Awesome thanks! Great tool btw!

Question for my learning: wouldn't lto affect the generated asm as it would affect inlining and subsequent optimizations?

@pacak
Copy link
Owner

pacak commented Mar 9, 2023

It might affect the final result in some cases - cross crate inlining perhaps, it should still produce the same results for a single create code because of -Ccodegen-units=1. Situation can probably be improved but for now I'm just fixing a regression.

@reisnera
Copy link

reisnera commented Mar 9, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants