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

check for std symbols #2

Open
gnzlbg opened this issue Nov 12, 2018 · 4 comments
Open

check for std symbols #2

gnzlbg opened this issue Nov 12, 2018 · 4 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@gnzlbg
Copy link

gnzlbg commented Nov 12, 2018

Test whether the final rlib or binary contain any std symbols or not.

The llvm-tools-preview component contains an llvm-nm that can be used to list all symbols in a binary, and the cargo-binutils sub-command can be used to find the appropriate llvm-nm binary for the current toolchain (https://internals.rust-lang.org/t/llvm-tools-a-new-rustup-component-for-binary-inspection-objdump-nm-size-and-profiling-profdata/7830/9).

With that one can check whether the final binary contains any std library symbols, a check that must pass independently of what all other checks say.

@hobofan
Copy link
Owner

hobofan commented Nov 12, 2018

I explored that route, but ultimately got stuck on isolating the binary part out of the *.rlib files. Haven't had a look at llvm-tools-preview, though.

I'm generally pro doing that, though most likely as an optional thing if it requires llvm-tools-preview to be added as a component.

@hobofan hobofan added enhancement New feature or request help wanted Extra attention is needed labels Jan 18, 2019
@hobofan
Copy link
Owner

hobofan commented Feb 4, 2019

@gnzlbg I tried out llvm-tools-preview and encountered the same problem as you did in rust-lang/rust#55729.

Apart from the The end of the file was unexpectedly encountered message the output does look pretty okay tough... I'm tempted to maybe build a hacky solution on top of that that ignores the exit code as long as the issue perists, and just grep the output for occurences of _<std.

Not the most beautiful solution, but probably the best we can do for post-compilation checks right now.

@gnzlbg
Copy link
Author

gnzlbg commented Feb 4, 2019

Sounds good, that's what I ended up doing more or less. One might need to try using the nm of the llvm toolchain first, and if that does not exist, then try to use the systems nm. FWIW I get the same errors using both, so maybe just using the system's nm is ok at least for the beginning.

@hobofan
Copy link
Owner

hobofan commented Jan 8, 2020

Good news! At a recent meetup someone told me that I *.rlib files are just a tar-ed archive that contains object files (sound like I could've figured that out earlier🤦‍♂). I built a local proof of concept that then parses the object files with gimli and looks for a std namespace, and it seems to work quite well.

I'm currently working on adding that as a new mode to cargo-nono and hopefully will get a release with that out soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants