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

rustc doesn't propagate custom link sections #31758

Closed
rasendubi opened this issue Feb 18, 2016 · 5 comments
Closed

rustc doesn't propagate custom link sections #31758

rasendubi opened this issue Feb 18, 2016 · 5 comments

Comments

@rasendubi
Copy link
Contributor

I have a library that outputs a custom link section (.isr_vector). That works fine, but when I link that library into the second one, there is no .isr_vector section in the result static library.

That worked before, so I bisected the issue down to a nightly build. The first bad nightly is 2016-02-12 (rustc 1.8.0-nightly (4b2c7030f 2016-02-12)). The last good one is 2016-02-11 (rustc 1.8.0-nightly (3f4227af1 2016-02-10)).

The full source is here: https://github.com/rasendubi/bkernel/tree/f788e32a2e0493420236cc2642cfaa9c4824203a. The link section is defined in https://github.com/rasendubi/bkernel/blob/f788e32a2e0493420236cc2642cfaa9c4824203a/stm32f4/isr_vector.rs.

@alexcrichton
Copy link
Member

Do you have a small reproduction that we can test against? It'd help to know how you're linking a library into a second one as that may have something going awry there as well.

@rasendubi
Copy link
Contributor Author

Pushed a small reproduction to https://github.com/rasendubi/rust_link_section. Steps to reproduce:

cargo build --release
objdump -h target/release/liblink_section.a | grep .custom_section

I also discovered the issue shows only with LTO enabled. Seems that it collects the section because nobody refers to it. Can I instruct the compiler to keep the section?

@alexcrichton
Copy link
Member

Ah it looks like this was caused by #30830 where we fixed LTO to internalize static symbols that weren't needed as part of the ABI. If you mark the symbol as #[no_mangle] for now that should do the trick.

We don't really exhaustively define how we retain symbols, however, especially for LTO, so this is indeed a little bit of a gray area as to what the "correct" behavior here is.

cc @arcnmx

rasendubi added a commit to rasendubi/bkernel that referenced this issue Feb 20, 2016
- data-layout is no longer needed in target file. (Changed in previous
  commit.)
  See rust-lang/rust#31367

- Symbols with custom section should be marked as no_mangle; otherwise,
  LTO will collect them.
  See rust-lang/rust#31758
@rasendubi
Copy link
Contributor Author

Thanks! Adding #[no_mangle] fixed my build.

I'm closing the issue now. Feel free to re-open if you expect any further activity.

@arcnmx
Copy link
Contributor

arcnmx commented Feb 21, 2016

As much as I would've liked link_section to be in the list of extern indicators, it's true that it isn't necessarily correct. See also rust-lang/rfcs#1459, there's definitely discussion to be had about what counts as an externally reachable symbol vs internal symbols that we simply don't want removed, etc.

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

No branches or pull requests

3 participants