x86_64-pc-windows-msvc when building with debug info: error LNK2017: 'ADDR32' relocation to '.debug_str' invalid without /LARGEADDRESSAWARE:NO

[briansmith]

When I change debug=false to debug=true in ring's Cargo.toml (for the release/bench/test profiles), the x86_64-pc-windows-msvc build fails with

error LNK2017: 'ADDR32' relocation to '.debug_str' invalid without /LARGEADDRESSAWARE:NO.

Apparently, This is due to https://llvm.org/bugs/show_bug.cgi?id=15393 and is caused by the presence of DWARF debugging info. IIRC, @alexcrichton said that DWARF debugging info was used for unwinding. But, I think that might have changed already? If so, can we drop the DWARF symbols from the x86_64-pc-windows-msvc build?

Note that in Cargo.toml we cannot (AFAICT) set a profile's debug setting on a per-platform basis.

[alexcrichton]

I would prefer to understand a little more here before we start turning things off, but unfortunately right now we can't turn off dwarf emission entirely as it's used for unwinding still (LLVM's SEH-based unwinding is unreliable in 3.7).

The minimal test case I've found so far is:

// compile with -Clto -g
extern crate libc;
extern crate winapi;
fn main() {}

It looks like this may just be related to the size of object files rather than optimization + dwarf info, if you remove -Clto it links just fine.

[briansmith]

we can't turn off dwarf emission entirely

It isn't necessary to turn off dward emission entirely. I'm assuming that when we omit "-g", then the DWARF info for unwinding is still being generated. If so, it would only be necessary to turn off whatever additional DWARF stuff gets added with "-g", ideally keeping the CV/PDB format debug info.

It looks like this may just be related to the size of object files rather than optimization + dwarf info

I can't do anything about the size.

If you remove -Clto it links just fine.

Yes, but I'd rather compile with LTO than with the extra debug info by default.

If I weren't using Cargo, then I could just change my build logic to omit the -g flag on Win64. But, I can't do that with Cargo, so some alternate solution is needed.

[alexcrichton]

Oh right, so I think this is where I'd probably like to understand a little more about what's causing this. We don't (to the best of my knowledge) emit any dwarf debug information with -g on MSVC, it should in theory be all PDB stuff. That being said, we don't request anything specific from LLVM, I think it just chooses the output format based on the target.

It'd be good to either (a) fix this in LLVM, (b) figure out a flag to pass to the linker, or (c) figure out how to prevent this in the frontend in a more surgical manner than "disable all debug info on msvc"

[briansmith]

It'd be good to either (a) fix this in LLVM, (b) figure out a flag to pass to the linker, or (c) figure out how to prevent this in the frontend in a more surgical manner than "disable all debug info on msvc"

Sure, but I think it is reasonable to implement that workaround until the problem is found, since it seems likely that it will take a while to do the better things.

[briansmith]

What is the current status of things, as far as this bug goes? Now, IIUC, LLVM's unwinding is being used so there's less (no?) reason to embed the DWARF debugging info? If so, then can we get rid of it so that debug=true can be used on optimized builds?

[alexcrichton]

Does this still reproduce for you? This may have been fixed by #31319, and my "minimal repro" seems to work.

[briansmith]

Yes, this still reproduces for me.

In particular, if I do cargo build --release, then the build succeeds, but if I do cargo test --release then the build fails with several errors like this:

• git clone https://github.com/briansmith/ring
• edit Cargo.toml to s/debug = false/debug = true/ in the [profile.release] section.
• cargo test --release

checkdigest.0.o : error LNK2017: 'ADDR32' relocation to '.debug_info' invalid without /LARGEADDRESSAWARE:NO

checkdigest is one of the examples (as cargo defines "example") of ring.

[retep998]

I compiled three binaries, the first is a Rust hello world with debug info, the second is without debug info, and the third is a C hello world. All using 64bit msvc.

So dwarf debug symbols are definitely not being produced anymore for x86_64-pc-windows-msvc and we can rule that out.

@briansmith What is the exact version of rust you are using?

[briansmith]

Thanks Peter. It turns out that I had a pre-rustup version of rustc in my path, so that even when rustup told me it had switched to rustc 1.10, I was really building with rustc 1.6. After I fixed that, I verified that at least as of Rust 1.9, the problem is fixed. So this can be closed!