Skip to content

Enable function sections with windows-gnu - #75604

Closed
mati865 wants to merge 2 commits into
rust-lang:masterfrom
mati865:mingw-ffunction-sections
Closed

Enable function sections with windows-gnu#75604
mati865 wants to merge 2 commits into
rust-lang:masterfrom
mati865:mingw-ffunction-sections

Conversation

@mati865

@mati865mati865 commented Aug 16, 2020

Copy link
Copy Markdown
Member

Passed tests locally on x86_64 with LLVM assertions enabled.

@rust-highfive

rust-highfive commented Aug 16, 2020

Copy link
Copy Markdown
Contributor

r? @ecstatic-morse

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 16, 2020
petrochenkov
petrochenkov reviewed Aug 16, 2020
View reviewed changes
Comment threadsrc/librustc_target/spec/windows_gnu_base.rs Outdated
@mati865
Enable function sections on windows-gnu
7c97ddf
@mati865
Stable-symbol-names test: compare only global symbols
b655027
With MinGW and specific flags symbol may end up in multiple sections in some cases like:
0000000000000000 p .pdata$_ZN20stable_symbol_names113mono_function17hd4880e88dec8766dE
0000000000000000 t .text$_ZN20stable_symbol_names113mono_function17hd4880e88dec8766dE
0000000000000000 r .xdata$_ZN20stable_symbol_names113mono_function17hd4880e88dec8766dE
0000000000000000 T _ZN20stable_symbol_names113mono_function17hd4880e88dec8766dE
This will cause an error when comparing that output directly with other library
that only imports the symbol since it will appear only once.
To avoid the issue pass "-g" to nm so only the global symbol (the one
with "T" letter) will be listed.
@mati865
mati865force-pushed the mingw-ffunction-sections branch from 14ee44a to b655027CompareAugust 16, 2020 20:26
@nagisa

nagisa commented Aug 16, 2020

Copy link
Copy Markdown
Member

IIRC the reason it was disabled until now was because on Windows there's an egregiously small limit on sections in object files, which then leads to compilation failures. Is windows-gnu not affected by this?

@mati865

mati865 commented Aug 16, 2020•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

Apparently it was disabled because of the LLVM assertions: #13846
LLVM supports doing it for both MSVC and GNU Windows targets. Short topic that made me try it again: mstorsjo/llvm-mingw#148

I have tried enabling it some time ago but got ui tests crashes.
Just recently I have noticed enabling ASLR or functions_sections had very similar (or even identical) crashes as one of my mistakes when working on #72049. To be exact the crashes happened when statics were imported from other DLLs without dllimport.
If you want I can verify tomorrow if this is unexpected "fallout" from #72049 or something else has fixed it.

@mstorsjo

mstorsjo commented Aug 17, 2020

Copy link
Copy Markdown

IIRC the reason it was disabled until now was because on Windows there's an egregiously small limit on sections in object files, which then leads to compilation failures. Is windows-gnu not affected by this?

FWIW, the limit on sections in an object file is higher if compiling in "big object" mode. IIRC GCC and/or MSVC require you to pass specific flags for enabling this, while LLVM enables this format automatically as needed.

@ecstatic-morse

ecstatic-morse commented Aug 19, 2020

Copy link
Copy Markdown
Contributor

r? @nagisa

@nagisa

nagisa commented Aug 21, 2020

Copy link
Copy Markdown
Member

@bors r+

@bors

bors commented Aug 21, 2020

Copy link
Copy Markdown
Collaborator

📌 Commit b655027 has been approved by nagisa

@borsbors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 21, 2020
@bors

bors commented Aug 21, 2020

Copy link
Copy Markdown
Collaborator

⌛ Testing commit b655027 with merge 18dd0795f6aecafa408c6b35e9b28d2798a6ea8a...

@bors

bors commented Aug 21, 2020

Copy link
Copy Markdown
Collaborator

💔 Test failed - checks-actions

@borsbors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 21, 2020
@mati865

mati865 commented Aug 21, 2020

Copy link
Copy Markdown
MemberAuthor

Appears to be bug fixed in binutils 2.32 I'll look for a workaround.

@mati865

mati865 commented Aug 22, 2020

Copy link
Copy Markdown
MemberAuthor

I can reproduce it locally with the same Binutils version as on CI, Binutils 2.34 are not affected.
I doubt we can raise minimal Binutils version to 2.32 (released 2019-02-02) soon, this will have to wait until the requirement can be bumped or we migrate to LLD for MinGW.

@mstorsjo do you remember if this is easily workaroundable in LLVM?

@mstorsjo

mstorsjo commented Aug 22, 2020

Copy link
Copy Markdown

I can reproduce it locally with the same Binutils version as on CI, Binutils 2.34 are not affected.
I doubt we can raise minimal Binutils version to 2.32 (released 2019-02-02) soon, this will have to wait until the requirement can be bumped or we migrate to LLD for MinGW.

@mstorsjo do you remember if this is easily workaroundable in LLVM?

What issue in particular are you referring to here?

@mati865

mati865 commented Aug 22, 2020•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

@mstorsjo I apologize I thought I had included the link. Here is ld.bfd bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=23872
The error:

 Mingw-w64 runtime failure:
Unknown pseudo relocation protocol version 16777216.

@mstorsjo

mstorsjo commented Aug 23, 2020

Copy link
Copy Markdown

@mstorsjo I apologize I thought I had included the link. Here is ld.bfd bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=23872
The error:

 Mingw-w64 runtime failure:
Unknown pseudo relocation protocol version 16777216.

Ah, that one.

I have one potential fix in mind - appending a final object file that contains .rdata contents that is aligned to 4 bytes, included as the last object file in the link command. The object file can be assembled from e.g. this:

 .section .rdata$zzzz
.align 4
.long 0

That should take care to make sure the end of the .rdata section is aligned to 4 bytes, avoiding that particular ld bug.

@mati865

mati865 commented Aug 24, 2020

Copy link
Copy Markdown
MemberAuthor

Unfortunately that didn't work. I'll just close it for now.

@mati865mati865 closed this Aug 24, 2020
@mati865
mati865 deleted the mingw-ffunction-sections branch November 3, 2022 19:52
@wesleywiserwesleywiser mentioned this pull request Nov 7, 2025
Closed
rust-borsBot pushed a commit that referenced this pull request Nov 7, 2025
@wesleywiser
Enable -Zfunction-sections by default for *-windows-{gnu,cygwin}
e23a5fc
The comment here was a bit misleading, #13846 was about an LLVM assertion
that failed when `-Zfunction-sections` was enabled. However, that bug
has been fixed for a long time and the actual issue was that older `ld`
versions would not correctly link binaries (see #75604 for the prior
attempt at this change). This bug was fixed in version 2.32 of binutils
and Rust now ships binutils 2.42 as of #119229 so we can remove this
workaround!
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@petrochenkovpetrochenkovpetrochenkov left review comments

Assignees

@nagisanagisa

Labels

S-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@mati865@rust-highfive@nagisa@mstorsjo@ecstatic-morse@bors@petrochenkov