cmd/link: using lld linker fails on Windows

[Keithcat1]

after the following commands:
set CGO_LDFLAGS=-fuse-ld=lld
go build

I get this error:

command-line-arguments

C:\go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
lld: error: unknown argument: -T
collect2.exe: error: ld returned 1 exit status
The argument which is causing this is :
-Wl,-T,C:\Users\Keith\AppData\Local\Temp\go-link-100899651\fix_debug_gdb_scripts.ld
I found a way to remove this one argument, but the resulting executable crashes when I start it.

[thanm]

I took a look at the most resource source code for LLD; The "-T" or "--script" option is supported only for ELF targets.

With that said, the reason that we introduced the use of the linker script in the first place was to work around a bug in ld.bfd (https://sourceware.org/bugzilla/show_bug.cgi?id=21459), so one would expect that we would not need the same workaround for lld.

The main issue then becomes figuring out which linker is being used when doing external linking on windows, which should be doable. I will see about sending a CL.

[thanm]

Interesting. Now looking at the script we're using:

SECTIONS
{
  .debug_gdb_scripts BLOCK(__section_alignment__) (NOLOAD) :
  {
    *(.debug_gdb_scripts)
  }
}
INSERT AFTER .debug_types;

Note the final line -- this refers to the ".debug_types" section, which as far as I know is not even generated by most compilers (clang doesn't emit it as far as I know, and gcc emits it only if you specifically as for it with a command line option).

Maybe we don't need the linker script after all?

[ianlancetaylor]

It will insert the fragment after where .debug_types in the default linker script, and that does exist, whether or not there is actually an input section named .debug_types.

That said, I do in fact see this in the default COFF/PE linker script:

  /* DWARF 4.  */
  .debug_types ${RELOCATING+BLOCK(__section_alignment__)} ${RELOCATING+(NOLOAD)} :
  {
    *(.debug_types${RELOCATING+ .gnu.linkonce.wt.*})
  }
  .zdebug_types ${RELOCATING+BLOCK(__section_alignment__)} ${RELOCATING+(NOLOAD)} :
  {
    *(.zdebug_types${RELOCATING+ .gnu.linkonce.wt.*})
  }

  /* For Go and Rust.  */
  .debug_gdb_scripts ${RELOCATING+BLOCK(__section_alignment__)} ${RELOCATING+(NOLOAD)} :
  {
    *(.debug_gdb_scripts)
  }
  .zdebug_gdb_scripts ${RELOCATING+BLOCK(__section_alignment__)} ${RELOCATING+(NOLOAD)} :
  {
    *(.zdebug_gdb_scripts)
  }

The .debug_gdb_scripts section was added May 15, 2017, and is in GNU binutils 2.29 and later. So it may be that we can simply drop the -T option, and tell people running old binutils versions to add it themselves via --extldflags.

[thanm]

Thanks @ianlancetaylor , that makes sense.

A lot of our gomotes still seem to be running older versions of binutils, so I can definitely still see the problem if remove the workaround.

[gopherbot]

Change https://golang.org/cl/278932 mentions this issue: cmd/link: avoid use of -T when linking with lld

[thanm]

I've sent a CL that should take care of the primary issue. @Keithcat1 if you are able to build Go from source, perhaps you can try it out once the CL goes in.

It would also be helpful to know exactly which version of lld you are testing against.

Verifying the CL turned out to be a bit more work than I had thought; the C compilers on our gomotes are pretty old (do not support -fuse-ld=lld). I tested using a toolchain from https://musl.cc/x86_64-w64-mingw32-native.zip, in combination with a copy of LLD extracted from https://github.com/llvm/llvm-project/releases/download/llvmorg-11.0.0/LLVM-11.0.0-win64.exe.

[Keithcat1]

At the time when I posted this issue, I was using LLD 10.0 and GCC 9 or GCC 10 as well. I was using MSYS64 to get GCC and LLD.

[thanm]

Thanks @Keithcat1 . Do you want me to hold the bug open, or can it be closed once the change is in?

[Keithcat1]

I haven't been able to verify yet that this works. Thanks for helping with this though.