[LLD] Version script support

[mati865]

Moving from #56

It's not top priority but would be nice to support it at some point.

[mati865]

Continuation to discussion in #56

Seems like reusing .def files created for link.exe isn't viable option because Binutils LD doesn't understand them.
Universal solution working for both LD and LLD is necessary because Rust calls CC (both GCC and Clang do work) so it cannot distinguish the linker.

Supporting LLD will have to wait until then.

[mstorsjo]

Seems like reusing .def files created for link.exe isn't viable option because Binutils LD doesn't understand them.

That's surprising - which aspect of them doesn't binutils ld support? As far as I know they handle them just fine; you pass the name of the def file as one of the input files, and it handles at least the normal list of exports that GNU ld, lld and msvc link.exe all handle the same.

[mati865]

Passed to Clang with "-Wl,C:\\Users\\mateusz\\AppData\\Local\\Temp\\rustcylZC2s\\list":

D:\msys64\mingw64\bin\ld:
  C:\Users\mateusz\AppData\Local\Temp\rustcNDaPN4\list: file format not recognized; treating as linker script
D:\msys64\mingw64\bin\ld:
  C:\Users\mateusz\AppData\Local\Temp\rustcNDaPN4\list:2: syntax error

Def file contents: https://gist.github.com/mati865/85265364bcaaacc101e33a77f059a896

[mstorsjo]

Three things come to mind:

• Would it work better if you gave the file a .def suffix?
• Not sure if GNU ld might have an issue with the $ chars in some of the symbol names
• Not sure if GNU ld might have an issue with the LIBRARY line without an actual dll file name - try either leaving it out or adding a dll name there

[mati865]

It's the same result (file format not recognized) when it's named list.def.
There is defparse code inside binutils repo but it appears to be used only by dlltool: https://github.com/bminor/binutils-gdb/search?p=1&q=defparse

[mstorsjo]

Works fine for me in a minimal testcase:

$ cat test.c
void a(void) {}
void b(void) {}
void c(void) {}
$ cat test.def
EXPORTS
a
b
$ x86_64-w64-mingw32-gcc -c test.c -o test.o
$ x86_64-w64-mingw32-ld --version
GNU ld (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
$ x86_64-w64-mingw32-ld test.o test.def -o test.dll -shared 
$ llvm-readobj --coff-exports test.dll

File: test.dll
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
Export {
  Ordinal: 1
  Name: a
  RVA: 0x1000
}
Export {
  Ordinal: 2
  Name: b
  RVA: 0x1007
}

[mati865]

Builds are taking quite some time but now I can confirm LD does work when LIBRARY is gone and the file has .def extension.
Thank you for your time!

[mati865]

Update on this topic:
I copied MSVC code for generating the script (modulo LIBRARY section) in rust-lang/rust#70852 and it causes regressions:

• DLLs have additional dependencies:
  • symbols exported via .def (bad):

    $ ntldd cci_const_block.dll
            std-979e3b2f81b3e5a5.dll => D:\Projekty\rust\build\x86_64-pc-windows-gnu\stage2\bin\std-979e3b2f81b3e5a5.dll (0x0000000000ef0000)
            KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x00000000016f0000)
            msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x00000000006e0000)
    

  • symbols exported via version-script (good):

    $ ntldd cci_const_block.dll
            KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x0000000000eb0000)
            msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x0000000000eb0000)
    

• linking to DLLs via implibs causes segfaults (direct linking to DLL with LD works):
  • .def (bad):

    $ nm libcci_const_block.dll.a | grep BLOCK_FN_DEF
    0000000000000000 I __imp__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000000000000 T _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    

  • version-script (good):

    $ nm const-block-cross-crate-fn/auxiliary/libcci_const_block.dll.a | grep BLOCK_FN_DEF
    0000000000000000 I __imp__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000000000000 I __nm__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    

  • the DLL:

    $ nm cci_const_block.dll | grep BLOCK_FN_DEF
    0000000067cc5000 R _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000067cc13b0 t _ZN15cci_const_block12BLOCK_FN_DEF3foo17h3d71b48312ebbcc6E
    

`.def` file from above case:

EXPORTS
  _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
  __rust_alloc
  __rust_alloc_zeroed
  __rust_dealloc
  __rust_realloc
  rust_metadata_cci_const_block_8787f43e282added376259c1adb08b80

`linker-script` from above case:

{
  global:
    _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE;
    __rust_alloc;
    __rust_alloc_zeroed;
    __rust_dealloc;
    __rust_realloc;
    rust_metadata_cci_const_block_8787f43e282added376259c1adb08b80;

  local:
    *;
};

I don't full understand what is going on so Rust support for LLD with MinGW targets will wait for now.

[mstorsjo]

Update on this topic:
I copied MSVC code for generating the script (modulo LIBRARY section) in rust-lang/rust#70852 and it causes regressions:

• DLLs have additional dependencies:

  • symbols exported via .def (bad):

    $ ntldd cci_const_block.dll
            std-979e3b2f81b3e5a5.dll => D:\Projekty\rust\build\x86_64-pc-windows-gnu\stage2\bin\std-979e3b2f81b3e5a5.dll (0x0000000000ef0000)
            KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x00000000016f0000)
            msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x00000000006e0000)
    

  • symbols exported via version-script (good):

    $ ntldd cci_const_block.dll
            KERNEL32.dll => C:\WINDOWS\SYSTEM32\KERNEL32.dll (0x0000000000eb0000)
            msvcrt.dll => C:\WINDOWS\SYSTEM32\msvcrt.dll (0x0000000000eb0000)
    

• linking to DLLs via implibs causes segfaults (direct linking to DLL with LD works):

  • .def (bad):

    $ nm libcci_const_block.dll.a | grep BLOCK_FN_DEF
    0000000000000000 I __imp__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000000000000 T _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    

  • version-script (good):

    $ nm const-block-cross-crate-fn/auxiliary/libcci_const_block.dll.a | grep BLOCK_FN_DEF
    0000000000000000 I __imp__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000000000000 I __nm__ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    

  • the DLL:

    $ nm cci_const_block.dll | grep BLOCK_FN_DEF
    0000000067cc5000 R _ZN15cci_const_block12BLOCK_FN_DEF17h2bbe18e6734ce46cE
    0000000067cc13b0 t _ZN15cci_const_block12BLOCK_FN_DEF3foo17h3d71b48312ebbcc6E
    

.def file from above case:
linker-script from above case:
I don't full understand what is going on so Rust support for LLD with MinGW targets will wait for now.

Was this with def files, with LLD? To narrow things down, if you have time, it could be useful to try applying that on a normal GCC/binutils based build, to see if that aspect is creating issues, or if it's just other aspects of LLD vs ld.bfd vs link.exe.

[mati865]

Those results are the same with ld.bfd and LLD. Though I mostly test ld.bfd since import libs are not always generated yet so using LLD requires a lot manual work.

[mstorsjo]

Those results are the same with ld.bfd and LLD. Though I mostly test ld.bfd since import libs are not always generated yet so using LLD requires a lot manual work.

Oh, ok, that's weird then. Maybe the def file generation scripts need to know about and handle some other mingw-ism...

[mati865]

Oh, ok, that's weird then. Maybe the def file generation scripts need to know about and handle some other mingw-ism...

I tried adding –export-all-symbols after reading https://sourceware.org/binutils/docs/ld/WIN32.html but builds failed because there were too many symbols.

I'll inspect ELF LLD code for version-script, probably adapting it for MinGW would be easier (and more time consuming) than using def files.

[mstorsjo]

I'll inspect ELF LLD code for version-script, probably adapting it for MinGW would be easier (and more time consuming) than using def files.

I've looked at it a few times, and version script seems to be a subset of full linker script, and linker script is essentially a script that controls the whole linker, which in the ELF linker is very closely integrated with the whole linker. But maybe it's possible to extract out the bits necessary for version script without bringing all of it. Having support for version script would indeed be great.

[mati865]

Oh, this part linking to DLLs via implibs causes segfaults (direct linking to DLL with LD works) applies only to the ld.bfd. LLD errors about missing symbols.

EDIT: Also those are isolated cases (from testsuite), def file works most of the time.

[SquallATF]

Was this with def files, with LLD? To narrow things down, if you have time, it could be useful to try applying that on a normal GCC/binutils based build, to see if that aspect is creating issues, or if it's just other aspects of LLD vs ld.bfd vs link.exe.

I think the other problem is ld.bfd not support lto, because llvm gold plugin not support PE/COFF target. and if use ld.bfd need rebuild mingw-w64 crt with binutils, otherwise it will cause link failure. By the way. is there any way let llvm gold plugin support PE/COFF like gcc lto plugin?