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

Only retain external static symbols across LTO #30830

Merged
merged 4 commits into from
Feb 12, 2016

Conversation

arcnmx
Copy link
Contributor

@arcnmx arcnmx commented Jan 11, 2016

contains_name(attrs, "no_mangle") ||
contains_name(attrs, "link_section") ||
contains_name(attrs, "linkage") ||
contains_name(attrs, "export_name")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #29676, this should use find_export_name_attr to avoid duplicating the literal string "export_name".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is the diagnostic parameter, and that this has to go through the CrateStore::is_extern_item trait. Constants should be used instead of string literals, but that's a change to be made to the entire compiler. I don't really feel that find_export_name_attr is the right way to go about this. I tried to thread it through and failed, maybe you can advise where I can get an instance of it in each of the two places it's needed?

@arcnmx
Copy link
Contributor Author

arcnmx commented Jan 12, 2016

... or nevermindish, removed those two. We can think about linkage later.

@arcnmx
Copy link
Contributor Author

arcnmx commented Jan 12, 2016

How does that look?

@@ -299,16 +299,16 @@ pub fn find_crate_name(attrs: &[Attribute]) -> Option<InternedString> {
}

/// Find the value of #[export_name=*] attribute and check its validity.
pub fn find_export_name_attr(diag: &Handler, attrs: &[Attribute]) -> Option<InternedString> {
pub fn find_export_name_attr(diag: Option<&Handler>, attrs: &[Attribute]) -> Option<InternedString> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to ensure that a &Handler gets threaded through to here on all control flow paths?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think both those contexts have access to a ty::ctxt which I believe should have a handle to this via some methods (probably through the Session itself)?

@alexcrichton
Copy link
Member

Thanks @arcnmx! Sorry for the delay, but feel free to ping a PR whenever you update it as unfortunately github doesn't send out notifications for that kind of event.

Can you be sure to add a test to this PR as well?

@bors
Copy link
Contributor

bors commented Feb 11, 2016

☔ The latest upstream changes (presumably #31487) made this pull request unmergeable. Please resolve the merge conflicts.

@arcnmx
Copy link
Contributor Author

arcnmx commented Feb 11, 2016

... I'm actually not sure how to test this. The test would be to ensure that LTO causes the removal of a symbol, which is mangled so I don't know how to reference it (and using no_mangle/export_name will inhibit its removal)...

@alexcrichton
Copy link
Member

Oh gah right I'm sorry, I think I thought that this was adding support for retaining symbols, not removing support for retaining non-#[no_mangle] symbols. In that case this looks good to me, sorry for the delay!

@bors: r+ 0ff055a

@bors
Copy link
Contributor

bors commented Feb 12, 2016

⌛ Testing commit 0ff055a with merge 4b2c703...

@bors bors merged commit 0ff055a into rust-lang:master Feb 12, 2016
yuriks added a commit to yuriks/tock that referenced this pull request Jul 30, 2016
The code appears to have been broken in rust-lang/rust#30830. This
commit uses no_mangle as a work-around, since that's special-cased by
the compiler and always kept.

A more proper solution would be to re-export the necessary symbols in
the final crate, which should also ensure that they're kept. This would
either introduce a platform dependency in the main crate, or require a
restructuring of the code so that the kernel binary is produced by the
platform code.
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 this pull request may close these issues.

3 participants