No worries - whenever you have time!

Hi guys,

I think this is better (we've been using it for a while successfully), I haven't had time to understand the tests enough to add some yet, but I'll take a look as soon as I can

FYI, I backported this and the other diff to llvm 10 and its all working nicely, now building all packages with lld without issue

This is actually wrong anyway

I'd probably also go for 2 also as the default, as long as its configurable then just a sensible default is good

As a side note, I fixed the Go linker and everything looks awesome now.

In D80390#2064941, @MaskRay wrote:

In D80390#2064929, @joewholden wrote:

In D80390#2064903, @MaskRay wrote:

In D80390#2064895, @joewholden wrote:

Ok so, just stumbled upon one issue but I'm not yet sure where the problem lies given how bad mips support is in Go:

ld: error: section type mismatch for .debug_line

/tmp/go-link-985122218/000010.o:(.debug_line): SHT_MIPS_DWARF
output section .debug_line: SHT_PROGBITS

I'm still testing though, so I'll see what I uncover...

According to https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCObjectFileInfo.cpp#L404 , .debug_line on MIPS should use SHT_MIPS_DWARF (different from all other targets). Go produced assembly should do the same. LLD has such a rigorous check for section type compatibility.

Go actually produces binaries that trip LLVM up quite often - another example is llvm-strip, I should probably file another bug for that though

GNU binutils are much more relaxed when it comes to these checks, so I expect Go elf tools don't get properly tested

I'd prefer we don't touch the section compatibility code in LLD. This should be easily fixable in Go assembly emitter.

FWIW GNU as 2.35 made things more rigorous as well https://sourceware.org/pipermail/binutils/2020-February/109945.html. GNU ld is still loose (even mixing SHT_REL and SHT_RELA is ok). They might keep that behavior for compatibility reasons. In LLD, these things don't work currently and there is no need to appease old versions of them.

In D80390#2064903, @MaskRay wrote:

In D80390#2064895, @joewholden wrote:

Ok so, just stumbled upon one issue but I'm not yet sure where the problem lies given how bad mips support is in Go:

ld: error: section type mismatch for .debug_line

/tmp/go-link-985122218/000010.o:(.debug_line): SHT_MIPS_DWARF
output section .debug_line: SHT_PROGBITS

I'm still testing though, so I'll see what I uncover...

According to https://github.com/llvm/llvm-project/blob/master/llvm/lib/MC/MCObjectFileInfo.cpp#L404 , .debug_line on MIPS should use SHT_MIPS_DWARF (different from all other targets). Go produced assembly should do the same. LLD has such a rigorous check for section type compatibility.

Ok so, just stumbled upon one issue but I'm not yet sure where the problem lies given how bad mips support is in Go:

In D80390#2050523, @atanasyan wrote:

In D80390#2049724, @MaskRay wrote:

• .quad foo - . is representable
• ld.so supports such relocation chain.
• D78590 can be fixed for MIPS
• D72228 can get rid of the FDECFIEncoding = dwarf::DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4; hack
• For various relocation processing tool, it supporting a relocation chain as easy as supporting an addition relocation type (R_MIPS_PC64), by, adding case R_MIPS_PC64:?

Let's wait result of testing by Joe Holden. Interesting question - should we generate these 64-bit pc-relative relocations in .eh_frame always or provide some command line option to switch behaviour?

MIPS "relocation chain" is a standard feature defined by ABIs and should be supported by various tools including linkers. BFD and Gold linkers support it even better then LLD because they can handle arbitrary set of relocations in a chain.