cmd/link: silently performs incorrect relocations when linking foreign objects

[infinity0]

For example, when linking syso files.

Adding go:cgo_import_dynamic helps but (1) it was recently disabled for security reasons for non-cgo files, then reenabled because solaris needs it, so it's unclear if this policy will persist in the long-run for all architectures, and (2) you need to specify it for specific symbols rather than for all symbols. In any case, an error should be raised with a hint on what to do, rather than succeeding silently with invalid output.

The equivalent thing in Haskell Just Works with no extra annotations.

[andybons]

@ianlancetaylor

[ianlancetaylor]

Can you show us a self-contained example?

Does it work if you use -ldflags=-linkmode=external?

Perhaps we should default to external linking mode in the presence of any syso files.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[FiloSottile]

Reopening, I can provide a test case from FiloSottile/ed25519-dalek-rustgo#1.

[andybons]

Removing the WaitingForInfo tag worked around GopherBot fighting you :P.

[pwaller]

@ianlancetaylor I encountered this issue while looking into #30890.

Also, whilst typing in my issue number I discovered the very next issue filed was also about relocations - interesting/amusing coincidence: #30891.

        .text
        .file   "-"
        .globl  exampleFunc      # -- Begin function exampleFunc
        .p2align        4, 0x90
        .type   exampleFunc,@function
exampleFunc:                     # @exampleFunc
.Lfunc_begin0:
        .cfi_startproc
        movzbl  .L__const.exampleFunc.one(%rip), %eax
        movl    %eax, 8(%rsp)
        retq
.Lfunc_end0:
        .size   exampleFunc, .Lfunc_end0-exampleFunc
        .cfi_endproc

        .type   .L__const.exampleFunc.one,@object # @__const.exampleFunc.one
        .section        .rodata.cst4,"aM",@progbits,4
        .p2align        2
.L__const.exampleFunc.one:
        .long   1                       # 0x1
        .size   .L__const.exampleFunc.one, 4

If I build this with as to produce a syso and go build, the relocation is missing in the resulting binary.

TEXT ·exampleFunc(SB),$0-8
  JMP exampleFunc(SB)

package main

func main() {
        println(exampleFunc())
}

func exampleFunc() uint

objdump -dr shows the relocation in the syso:

0000000000000000 <exampleFunc>:
   0:   0f b6 05 00 00 00 00    movzbl 0x0(%rip),%eax        # 7 <exampleFunc+0x7>
                        3: R_X86_64_PC32        .L__const.exampleFunc.one-0x4
   7:   89 04 24                mov    %eax,8(%rsp)
   a:   c3                      retq   

but it's missing in the go binary:

0000000000401000 <exampleFunc>:
  401000:       0f b6 05 00 00 00 00    movzbl 0x0(%rip),%eax        # 401007 <exampleFunc+0x7>
  401007:       89 04 24                mov    %eax,8(%rsp)
  40100a:       c3                      retq   

[AndrewGMorgan]

So far as I can tell the reason this fails is something to do with the cross linking between the .text sectional reference and the .rodata.cst4 section data. If you convert this assembly with sed, as follows:

$ sed -i -e 's/.*\.rodata\..*/\t.text/' file.s

and try to compile that to a .syso file it appears to Go link (internal) correctly.

What this sed magic is doing is putting the data that is initially added to the .rodata.cst4 section into the .text section instead. Relative addressing within the .text section doesn't seem to be a problem.

This fixup isn't needed for external linking because that leverages the gcc/binutils toolchain and these cross sectional relationships appear to be fully supported there.

[AndrewGMorgan]

(I should say I've been trying to get to the bottom of https://bugzilla.kernel.org/show_bug.cgi?id=216610 and seding my way through that I found the above workaround. Hopefully there is a better way!)