From: Martin S. <ma...@ma...> - 2022-09-09 11:55:49
|
On Fri, 9 Sep 2022, Matthew Lugg wrote: >> Hmm, to dig further, can you provide the following: >> - The command you used for disassembling the bitcode from the LTO object >> file (to save me time from having to look it up, since I don't think I've >> done that before) >> - The actual LTO object file produced at this stage >> - The output of -E -dD for the test file, i.e. "zig cc -target >> x86_64-windows-gnu test.c -E -dD" (I presume that -flto shouldn't make any >> difference here, but who knows?) >> - The output of -S -emit-llvm for the test file (which should be the LLVM IR >> before it goes into the object file) > > The files you requested are all attached. Thanks! Although, Sourceforge's mailing list strips almost all attachments except for a small subset of suffixes :-( But anyway, I think I've figured it out. > The command for disassembling bitcode is just 'llvm-dis obj.o', which > will produce an 'obj.o.ll'. Ah, thanks! FWIW, instead of requesting another round, I downloaded a copy of zig and tried it out for myself. If I compile one object file with "zig cc -target .. test.c -c -o test.o -flto", I have one object file which I can successfully link with llvm-mingw. So the fault isn't with Clang. If I try to link the same object file with zig, with "zig cc -target .. test.o -o test.exe", it succeeds. But if I pass -flto to the linking command - it fails. The reason for that seems to be that zig builds all of the mingw-w64 crt files in LTO mode too, and links against them, if -flto is specified. I don't have a good explanation yet for exactly why lld fails to resolve the symbol in this case. It does load the right object file though (by passing "-verbose -demangle:no" to the lld-link command, I can see that it outputs "Loaded msvcrt-os.lib(rand_s.obj) for __imp_rand_s"). But for some reason, it fails to connect the dots for these symbols... So that concludes the hunt for the root cause - symbol resolution with all the various COFF quirks, with LTO involved, is a bit tricky at times, and this seems to be a bug there. (I can try to look into it later at some point maybe, but maybe with a bit lower priority.) With that in mind, I think it can make sense to include this symbol in the mingw-w64 crt source even if it shouldn't strictly be needed due to _SECIMP being dllimport - especially since the other similar symbols seems to be doing the same. // Martin |