LLD?

Question

LLD?

opened this issue 10 years ago · comments

MinGW's linker is painfully slow. Do you know is it possible to compile and use LLD for windows builds as well?

Thomas Pöchtrager · Answer 1 · Tue Nov 11 2014 03:02:53 GMT+0800 (China Standard Time)

No, probably not. Seems like lld does not support the GNU linking scheme for MinGW.

$ i686-w64-mingw32-clang ~/tmp/test.c -c

$ lld -flavor gnu -target i686-w64-mingw32 test.o
lld: unknown input file format for file test.o

Doing some link.exe like craziness:

$ lld -flavor link /MACHINE:x86 \
  test.o \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/crt2.o \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/crtbegin.o \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_eh.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmoldname.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libadvapi32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libshell32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libuser32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libkernel32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_eh.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmoldname.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmingwex.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a \
  /usr/lib/gcc/i686-w64-mingw32/4.9-win32/crtend.o

... doesn't work either:

lld warning: warning: ignoring unknown argument: -aligncomm:___mingw_winmain_lpCmdLine,2
warning: ignoring unknown argument: -aligncomm:___mingw_winmain_hInstance,2

lld warning: warning: ignoring unknown argument: -aligncomm:___native_startup_lock,2
warning: ignoring unknown argument: -aligncomm:___native_startup_state,2

lld warning: warning: ignoring unknown argument: -aligncomm:___onexitend,2
warning: ignoring unknown argument: -aligncomm:___onexitbegin,2

lld warning: warning: ignoring unknown argument: -aligncomm:___DTOR_LIST__,2
warning: ignoring unknown argument: -aligncomm:___CTOR_LIST__,2

Undefined symbol: /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/crt2.o: __set_invalid_parameter_handler
Undefined symbol: <entry>: _wmainCRTStartup
Undefined symbol: /usr/lib/gcc/i686-w64-mingw32/4.9-win32/../../../../i686-w64-mingw32/lib/../lib/crt2.o: __image_base__
symbol(s) not found

Probably the result of MinGW being unsupported by lld (the same arguments work with ld).
Or it's just too early, lld is nowhere near complete afaik.

On the other side, I have never had any problems with GNU ld.
Is there any particular library you have problems with?
Have you tried stripping debug symbols out of libraries before linking?

Deleted user · Answer 2 · Tue Nov 11 2014 06:19:43 GMT+0800 (China Standard Time)

Yea, I link my applications against libraries without debug symbols, optimized by -O3 (maybe -Os will reduce some time, I should try that too), but it still slow since I link a lot of them. Compile time of each C++ source file is around 1 second, linking is 10-15 seconds or so...

Thank you for your research, Tom! LLD is, indeed, isn't done yet and it's understandable why it doesn't work with MinGW...

Thomas Pöchtrager · Answer 3 · Wed Nov 12 2014 02:16:08 GMT+0800 (China Standard Time)

You are welcome.

I have never had such crazy long link times, not even when building huge projects,
like LLVM/Clang (without debug symbols).

Maybe you are running out of memory (i.e. swapping takes place)?
Have you checked if the linker is running at 100% cpu time?

LLD is, indeed, isn't done yet and it's understandable why it doesn't work with MinGW...

Yeah, I think there is actually just one person working on the lld Windows target.

martell · Answer 4 · Mon Jun 08 2015 09:39:11 GMT+0800 (China Standard Time)

@tpoechtrager There is now 2 people :)

llvm-mirror/lld#3
I have it linking correctly in ld emulation mode for x86_64 and I am merging upstream ;)
Still having issue resolving symbols on i686 and armv7

Thomas Pöchtrager · Answer 5 · Sat Jun 13 2015 00:57:04 GMT+0800 (China Standard Time)

@martell:

Finally MinGW support for LLD 😄. Keep up the good work!

Now if someone would also take care of clang's MinGW driver...

martell · Answer 6 · Sat Jun 13 2015 01:04:00 GMT+0800 (China Standard Time)

@tpoechtrager I've done that as well.
The mingw-driver is part of the clang package in msys2
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-clang

I also added armv7-w64-mingw32 as a target option for arm win32 via mingw-w64
That's not fully ready yet but will be soon.
Must work on building mingw-w64 completely with clang and without gcc soon :)

martell · Answer 7 · Sat Jun 13 2015 01:19:54 GMT+0800 (China Standard Time)

@tpoechtrager I would like to ask for help with something though and based on the project you have here you would be perfectly suited to helping me with this issue.

When calling dlltool it uses binutils AS to turns defs into .a libs in mingw-w64
I want to replace this with clang but --as=clang doesn't work as well as we want :(
This is very important for 2 reasons

arm because we obviously don't have gcc or binutils for armv7 win32
we should be able to build mingw-w64 without gcc or binutils at all :)

Thomas Pöchtrager · Answer 8 · Sat Jun 13 2015 01:30:55 GMT+0800 (China Standard Time)

@martell: I have taken a quick look at it, first of all, good job.

However, I came across a few things that could be tweaked:

You should really get rid of the hardcoded -lpthread, libwinpthread.dll is a really annoying dependency.
Looking for headers in /usr/<triple>/ won't work on everywhere, especially not on Linux where every distribution is doing its own packaging madness.

I could help out with the later one once I have enough time for it. I would be really interested in moving wclang's search logic directly into the clang driver.

Must work on building mingw-w64 completely with clang and without gcc soon :)

I would put that on a low priority list, libc++ would be of way more interest. Nobody really cares if a few crt object files are built by gcc instead of clang (at least not for now 😄).

Edit: Never mind, I see you already have a libc++ package...

When calling dlltool it uses binutils AS to turns defs into .a libs in mingw-w64
I want to replace this with clang but --as=clang doesn't work as well as we want :(
This is very important for 2 reasons

Sorry, I have no idea about Windows + ARM...

martell · Answer 9 · Sat Jun 13 2015 02:12:55 GMT+0800 (China Standard Time)

However, I came across a few things that could be tweaked:
You should really get rid of the hardcoded -lpthread, libwinpthread.dll is a really annoying dependency.

This was mostly taken because it was a default link library for gcc so it was made to act the same.
I do see your point though. There should be an option to add it instead.

Looking for headers in /usr// won't work on everywhere, especially not on Linux where every distribution is doing its own packaging madness.
I could help out with the later one once I have enough time for it. I would be really interested in moving wclang's search logic directly into the clang driver.

Yes the focus here has been mostly for a windows host and not linux
Any improvements here would be very welcome

I would put that on a low priority list, libc++ would be of way more interest. Nobody really cares if a few crt object files are built by gcc instead of clang (at least not for now 😄).

Edit: Never mind, I see you already have a libc++ package...

Well my thinking here was on using compiler-rt instead of libgcc
The libc++ package isn't fully ready yet :)

Sorry, I have no idea about Windows + ARM...

Well this isn't so much about windows on ARM its more about being able to use clang instead of AS.
I'm told that we should be able to do this, of course I would like to do this on i686 first.
It should be possible because clang can emit assembly just like binutils and gcc

Thomas Pöchtrager · Answer 10 · Sat Jun 13 2015 02:37:34 GMT+0800 (China Standard Time)

This was mostly taken because it was a default link library for gcc so it was made to act the same.

You are right, my MinGW installation is doing the same (probably because of --enabled-threads=posix), quite awful.

Yes the focus here has been mostly for a windows host and not linux
Any improvements here would be very welcome

Sure thing! I will look at it soon.

Well my thinking here was on using compiler-rt instead of libgcc
The libc++ package isn't fully ready yet :)

compiler-rt would be really interesting too, especially because of all the sanitizer stuff.

Well this isn't so much about windows on ARM its more about being able to use clang instead of AS.
I'm told that we should be able to do this, of course I would like to do this on i686 first.
It should be possible because clang can emit assembly just like binutils and gcc

Have you tried --as llvm-as instead of --as clang?

Deleted user · Answer 11 · Wed Jul 22 2015 08:49:39 GMT+0800 (China Standard Time)

@tpoechtrager @martell jesus christ, Martell, I've just compiled an openFrameworks application with Clang on Windows! I'll write a post about it on my blog...

martell · Answer 12 · Wed Jul 22 2015 10:06:09 GMT+0800 (China Standard Time)

sounds cool :)

In the last 2 weeks I have successfully built a mingw-w64 compiler with clang only.
We can throw gcc in the bin now :D
s/bin/trash/

I had many of the patches broken down and merged

http://reviews.llvm.org/D11087
http://reviews.llvm.org/D11088
http://reviews.llvm.org/D11085
http://reviews.llvm.org/D11071
http://reviews.llvm.org/D11075
http://reviews.llvm.org/D11237

As well as many patches went into mingw-w64 to support it being built with clang :)

If http://reviews.llvm.org/D11237 makes the 3.7 release I will do a package on it

Looking forward to your blog post :)

Thomas Pöchtrager · Answer 13 · Fri Jul 24 2015 01:30:34 GMT+0800 (China Standard Time)

@martell: Very well done! Clang+MinGW feels a lot better now.

Whenever you have a little bit of time, it would be great if you could have a look at:

https://llvm.org/bugs/show_bug.cgi?id=24182

Thanks!

martell · Answer 14 · Fri Jul 24 2015 02:09:45 GMT+0800 (China Standard Time)

@tpoechtrager: they have opted to disable that option by default because mingw.org compilers don't have it. It's very easy to change but they won't merge that change.
See the comments in http://reviews.llvm.org/D11087

It's a mingw-w64 issue, they should support c11 threads and we should not have to link with -pthread by default

Thomas Pöchtrager · Answer 15 · Fri Jul 24 2015 03:07:07 GMT+0800 (China Standard Time)

@martell: Having c11 thread support won't fix the issue for libstdc++, they are using pthreads. I don't want to hack the clang driver, I would like to have clang to link pthread by default (with -Wl,--as-needed) if the lib is present in <sysroot>/lib, or at least when -stdlib=libstdc++ is used.

The same applies to libc++, https://github.com/llvm-mirror/libcxx/blob/master/include/thread#L101.
While the <atomic> header seems to use c11...

Thomas Pöchtrager · Answer 16 · Fri Jul 24 2015 04:48:34 GMT+0800 (China Standard Time)

@martell: btw, the darwin driver is doing a similar approach with libcompiler_rt, the library only gets linked when it's installed.

martell · Answer 17 · Fri Jul 24 2015 15:10:31 GMT+0800 (China Standard Time)

@tpoechtrager: I'll have a look at this.
I way I had though of doing it would be to find out if we are using mingw.org or mingw-w64 toolchains and then do it based on that. I'll get some feedback first however from a few devs over there

Thomas Pöchtrager · Answer 18 · Fri Jul 24 2015 17:30:07 GMT+0800 (China Standard Time)

@martell: MinGW-w64 can also be built without winpthreads, it's gcc's --enable-threads=posix configure option.

martell · Answer 19 · Fri Jul 24 2015 17:38:56 GMT+0800 (China Standard Time)

Ahh yea that is very true actually.
I'll have a look at the darwin code and see if I can come up with something