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.

Sign up for GitHub

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

Jump to bottom

-ffunction-sections triggers an LLVM assert on windows #13846

Closed
alexcrichton opened this issue Apr 29, 2014 · 9 comments
Closed

-ffunction-sections triggers an LLVM assert on windows #13846

alexcrichton opened this issue Apr 29, 2014 · 9 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. O-windows-gnu Toolchain: GNU, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

It's the same assert as seen by #13793. I suspect that they are related bugs, and that this is likely an upstream LLVM bug.

This is a tracking issue for this for now. I'm going to turn off -ffunction-sections for windows.
@klutzy klutzy mentioned this issue Aug 12, 2014
Merged
@klutzy
Copy link
Contributor

klutzy commented Aug 18, 2014

#13793 issue has been fixed now, but it seems that other obscure bug exists in llvm or linker.
From #16450 failure log:

note: i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2e78): undefined reference to `driver::config::cgsetters::ar::h3bd933d9f589e8e9UWy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2e8c): undefined reference to `driver::config::cgsetters::linker::h257f0348e654864fgXy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2ea0): undefined reference to `driver::config::cgsetters::link_args::h83c0025909f670c1CXy'
i686-pc-mingw32\stage1\bin\rustlib\i686-pc-mingw32\lib\rustc-4e7c5e5c.o:(.data+0x2eb4): undefined reference to `driver::config::cgsetters::target_cpu::h3ec762698261dbe8YXy'
...

Linker failed to find driver::config::cgsetters::* functions so emitted undefined reference error on win-32-nopt-c setting.
However, stage1 has passed on win-32-opt setting. (Both reproduced on my machine too.)

@frewsxcv
Copy link
Member

frewsxcv commented Feb 2, 2015

@klutzy Are you able to reproduce those 'obscure bugs' with the latest Rust?

@vadimcn
Copy link
Contributor

vadimcn commented Feb 22, 2015

I re-enabled function sections on Windows in the current master branch, and it compiled and passed tests without errors.
However... I am not seeing any reductions in the size of executables. On the contrary, my hello_world.exe has gotten bigger! Rust nightly creates a 2.8MB file, whereas this modified version - 3.2MB.

@alexcrichton
Copy link
Member Author

It is expected that -ffunction-sections does indeed increase the size of the resulting object if nothing is eliminated (lots more sections need to be described). That being said I'm pretty surprised that nothing was eliminated. Are we sure that ld in mingw-w64 has this implemented and working?

@vadimcn
Copy link
Contributor

vadimcn commented Feb 23, 2015

It is expected that -ffunction-sections does indeed increase the size of the resulting object if nothing is eliminated (lots more sections need to be described).

I am talking about size of the final executable, not about rlib. I thought all text/data sections get merged during linking. Is there some residual per-section overhead?

Are we sure that ld in mingw-w64 has this implemented and working?

Good question... There was a patch enabling --gc-sections, however the bug is still open.

@vadimcn
Copy link
Contributor

vadimcn commented Feb 23, 2015

... and the answer is ... NO

@alexcrichton
Copy link
Member Author

I thought all text/data sections get merged during linking. Is there some residual per-section overhead?

Oh you may be right. I think I'm forgetting the exact specifics but what you're saying sounds right. Maybe there's a mixture of the two happening on windows?

... and the answer is ... NO

:(

@alexcrichton alexcrichton mentioned this issue Jun 18, 2015
Closed
47 tasks
@alexcrichton alexcrichton added O-windows-gnu Toolchain: GNU, Operating system: Windows and removed O-windows Operating system: Windows labels Dec 21, 2015
@brson brson added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 1, 2017
@brson
Copy link
Contributor

brson commented Jun 1, 2017

Kind of a wishlist feature, so closing. We just have to remember this problem if somebody ever tries to turn -ffunction-sections on again. Reopen if you disagree.

@brson brson closed this as completed Jun 1, 2017
@oli-obk oli-obk mentioned this issue Sep 6, 2017
Open
nivkner added a commit to nivkner/rust that referenced this issue Oct 7, 2017
@nivkner
address more FIXME whose associated issues were marked as closed
e0ac65e 
update FIXME(rust-lang#6298) to point to open issue 15020
update FIXME(rust-lang#6268) to point to RFC 811
update FIXME(rust-lang#10520) to point to RFC 1751
remove FIXME for emscripten issue 4563 and include target in `test_estimate_scaling_factor`
remove FIXME(rust-lang#18207) since node_id isn't used for `ref` pattern analysis
remove FIXME(rust-lang#6308) since DST was implemented in rust-lang#12938
remove FIXME(rust-lang#2658) since it was decided to not reorganize module
remove FIXME(rust-lang#20590) since it was decided to stay conservative with projection types
remove FIXME(rust-lang#20297) since it was decided that solving the issue is unnecessary
remove FIXME(rust-lang#27086) since closures do correspond to structs now
remove FIXME(rust-lang#13846) and enable `function_sections` for windows
remove mention of rust-lang#22079 in FIXME(rust-lang#22079) since this is a general FIXME
remove FIXME(rust-lang#5074) since the restriction on borrow were lifted
@mati865 mati865 mentioned this issue Aug 16, 2020
Closed
@mati865
Copy link
Contributor

mati865 commented Aug 26, 2020

FTR this feature works fine nowadays but it causes LD older than 2.32 to misalign relocations information, LLD is unaffected.
Remains disabled for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. O-windows-gnu Toolchain: GNU, Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@alexcrichton @brson @frewsxcv @mati865 @klutzy @vadimcn