On Wed, Sep 07, 2022 at 10:55:40PM +0300, Martin Storsjö wrote:
> On Wed, 7 Sep 2022, Matthew Lugg wrote:
>
> > The case I was working with was compiling C sources using Zig (a programming
> > language and compiler toolchain) - I realised the build was failing with
> > this
> > missing symbol in non-debug modes, and eventually narrowed the issue down to
> > LTO. Looking at the other files around in mingw-w64-crt/secapi, I found that
> > other files (e.g. memcpy_s.c) seem to generally define a "raw" variant of
> > the
> > function like this, and that doing it here does indeed resolve the compile
> > error.
>
> Indeed they do, and they are also declared with _SECAPI in the same way. So
> the fix probably is consistent with the others in that aspect.
>
> > I should mention that I had trouble reproducing the issue directly with
> > clang,
> > because it really didn't want to do LTO on code targeting PE for whatever
> > reason
>
> FWIW, LTO works fine with Clang based toolchains from e.g.
> https://github.com/mstorsjo/llvm-mingw/releases.
I was unable to get this to work - I pulled down
llvm-mingw-20220906-msvcrt-ubuntu-18.04.x86_64, but attempting to compile with
LTO gave the following output (which I also get with my system Clang install):
$ ./llvm-mingw-20220906-msvcrt-ubuntu-18.04-x86_64/bin/clang -target
x86_64-windows-gnu -flto test.c
clang-15: error: 'x86_64-unknown-windows-gnu': unable to pass LLVM bit-code
files to linker
$
Am I getting the usage wrong somehow?
> > - but I'm confident the issue is outside of the Zig project since 'zig
> > cc' is simply a convenience wrapper around Clang.
>
> Actually, it's not quite that clear cut.
>
> There have been numerous issues with Zig's intergration of mingw-w64. Even
> if "zig cc" only invokes Clang, Zig carries its own packaging of the files
> from mingw-w64-crt and doesn't build them according to the upstream build
> system, but Zig's own very much simplified rules, missing some source files
> (exactly which files go into which library is arch specific, etc).
>
> Although in this case, I kinda doubt that this is the issue.
I was unaware such issues had existed, that's interesting.
> > I don't understand how the dllimport system works well enough to comment on
> > the
> > correct fix here, but here's my basic guess: since dllimport only affects
> > the
> > symbol name on the compiler level rather than the source level, my
> > assumption is
> > that it's simply not applying to the LLVM bitcode generated (whereas it
> > does for
> > generated object files).
>
> No, that guess isn't correct - dllimport does get carried along in the LLVM
> bitcode generated.
>
> > If that's the case, it's possible this is actually an upstream issue in
> > Clang
>
> I'd just suggest that you stop guessing whom to blame here, it doesn't add
> anything of value and just distracts from the actual known facts here.
Fair enough, apologies.
> I'd like to see a repro of the issue; ideally in C reproable with llvm-mingw
> (but I just tried calling rand_s in a build with LTO there, and that worked
> just fine). So if that's not possible, at least a minimal way of reproducing
> the issue with C code built via Zig - is that possible?
>
> I tried this:
>
> $ cat rand_s.c
> #define _CRT_RAND_S
> #include <stdlib.h>
>
> int main(int argc, char* argv[]) {
> unsigned int foo = argc;
> rand_s(&foo);
> return 0;
> }
> $ x86_64-w64-mingw32-clang rand_s.c -o rand_s.exe -flto=full
> $ x86_64-w64-mingw32-clang rand_s.c -o rand_s.exe -flto=thin
>
> Both of these commands executed just fine.
That example fails when compiled with 'zig cc' and LTO (on Zig
0.10.0-dev.3885+a7661f115, the latest binary at the time of writing):
$ zig cc -target x86_64-windows-gnu test.c -flto
LLD Link... lld-link: error: undefined symbol: __declspec(dllimport) rand_s
>>> referenced by
>>> /home/mlugg/.cache/zig/o/933731dad30836773c08475bc613aee1/a.exe.lto.obj:(main)
$ zig cc -target x86_64-windows-gnu test.c -fno-lto
$
Using -v I can see the clang commands being invoked - the link command is as
follows:
lld-link -ERRORLIMIT:0 -NOLOGO -DEBUG -STACK:16777216 -MACHINE:X64
-INCLUDE:_tls_index
-OUT:/home/mlugg/.cache/zig/o/933731dad30836773c08475bc613aee1/a.exe
-IMPLIB:/home/mlugg/.cache/zig/o/933731dad30836773c08475bc613aee1/test.lib
/home/mlugg/.cache/zig/o/feec09a940302f3ed1289cbe205e0861/test.obj -lldmingw
-ALTERNATENAME:__image_base__=__ImageBase
/home/mlugg/.cache/zig/o/7864548b5a6871c6b8f13b96767185b7/crt2.obj
/home/mlugg/.cache/zig/o/7d336b794436e8815d552f0ec9da139b/mingw32.lib
/home/mlugg/.cache/zig/o/2f2968e7539871e99bf0375c4b38a5ec/mingwex.lib
/home/mlugg/.cache/zig/o/841b3c0a445f9e28bd1636b108037498/msvcrt-os.lib
/home/mlugg/.cache/zig/o/cf234a7783060ad4cfc515aa473f7dbb/ssp.lib
/home/mlugg/.cache/zig/o/9809a6d835a2cdf0b8cdac6a8bbf2e77/compiler_rt.lib
/home/mlugg/.cache/zig/o/923b282956e047e56af72a50764754f3/advapi32.lib
/home/mlugg/.cache/zig/o/98ffb1f446cc7c1abfb72cacf750fca6/kernel32.lib
/home/mlugg/.cache/zig/o/2e12499b3a4fb4245530bc01c9e9b441/msvcrt.lib
/home/mlugg/.cache/zig/o/eaa6e5c0a60c48e4fc76caf67745ac37/ntdll.lib
/home/mlugg/.cache/zig/o/5a2a7c2045f0604c9235a34b2f625c52/shell32.lib
/home/mlugg/.cache/zig/o/9780e20985bf925333cca2accf798bca/user32.lib
You'll know better than me which of these libs contains the relevant function.
I tried compiling with -c with both clang and zig cc and disassembling the
bitcode to LLVM IR, and as far as I can tell the lines relevant to rand_s don't
have any major differences (the one compiled with zig cc has 'noundef' on the
parameter but that's all).
--
Matthew
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
