diff options
| author | Yuki Okushi <huyuumi.dev@gmail.com> | 2019-11-12 16:36:07 +0900 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-11-12 16:36:07 +0900 |
| commit | 7596d34ea13b9401635fb159af9c1fd8df5adc78 (patch) | |
| tree | f69e4227841699e33ccbb870e5d949b8cbb367b0 | |
| parent | 86df2f6737d8c76d5dd577ebef1842f8657a59fb (diff) | |
| parent | d153f4f4936efc8039489083f5561070cf5de029 (diff) | |
| download | rust-7596d34ea13b9401635fb159af9c1fd8df5adc78.tar.gz rust-7596d34ea13b9401635fb159af9c1fd8df5adc78.zip | |
Rollup merge of #66257 - mati865:long-section-names-no-more, r=alexcrichton
Drop long-section-names linker workaround for windows-gnu If we can trust objdump Rust doesn't emit sections loaded at runtime longer than 8 characters on windows-gnu (but still does on linux-gnu), debug sections are not affected by that limit. I've ran tests and built few crates using exactly the same mingw-w64 version as Rusts CI just fine using **x86_64** toolchain. The motivation for this change is making LLD work (it doesn't support `--enable-long-section-names`) with this target without hacks. Bit of history: The behaviour of LD changed in Binutils 2.20 released on 2009-10-16 and `--enable-long-section-names` was added to return to the old non conformant behaviour. Looking at the comment I can only guess there was a bug fixed in newer versions. This workaround was added in https://github.com/rust-lang/rust/pull/13315 half a decade ago.
| -rw-r--r-- | src/librustc_target/spec/windows_base.rs | 27 |
1 files changed, 0 insertions, 27 deletions
diff --git a/src/librustc_target/spec/windows_base.rs b/src/librustc_target/spec/windows_base.rs index 38db9cd356c..ce7b338345c 100644 --- a/src/librustc_target/spec/windows_base.rs +++ b/src/librustc_target/spec/windows_base.rs @@ -4,33 +4,6 @@ use std::default::Default; pub fn opts() -> TargetOptions { let mut pre_link_args = LinkArgs::new(); pre_link_args.insert(LinkerFlavor::Gcc, vec![ - // And here, we see obscure linker flags #45. On windows, it has been - // found to be necessary to have this flag to compile liblibc. - // - // First a bit of background. On Windows, the file format is not ELF, - // but COFF (at least according to LLVM). COFF doesn't officially allow - // for section names over 8 characters, apparently. Our metadata - // section, ".note.rustc", you'll note is over 8 characters. - // - // On more recent versions of gcc on mingw, apparently the section name - // is *not* truncated, but rather stored elsewhere in a separate lookup - // table. On older versions of gcc, they apparently always truncated th - // section names (at least in some cases). Truncating the section name - // actually creates "invalid" objects [1] [2], but only for some - // introspection tools, not in terms of whether it can be loaded. - // - // Long story short, passing this flag forces the linker to *not* - // truncate section names (so we can find the metadata section after - // it's compiled). The real kicker is that rust compiled just fine on - // windows for quite a long time *without* this flag, so I have no idea - // why it suddenly started failing for liblibc. Regardless, we - // definitely don't want section name truncation, so we're keeping this - // flag for windows. - // - // [1] - https://sourceware.org/bugzilla/show_bug.cgi?id=13130 - // [2] - https://code.google.com/p/go/issues/detail?id=2139 - "-Wl,--enable-long-section-names".to_string(), - // Tell GCC to avoid linker plugins, because we are not bundling // them with Windows installer, and Rust does its own LTO anyways. "-fno-use-linker-plugin".to_string(), |