Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
infinity0 opened this issue Mar 9, 2018 · 8 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@infinity0
Copy link

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 andybons added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 9, 2018
@andybons
Copy link
Member

andybons commented Mar 9, 2018

@ianlancetaylor

@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 12, 2018
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 12, 2018
@andybons andybons added this to the Unplanned milestone Mar 26, 2018
@gopherbot
Copy link

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
Copy link
Contributor

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

@FiloSottile FiloSottile reopened this Apr 12, 2018
@andybons andybons removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 13, 2018
@andybons andybons reopened this Apr 13, 2018
@andybons
Copy link
Member

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

@pwaller
Copy link
Contributor

pwaller commented Mar 26, 2019

@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
Copy link
Contributor

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
Copy link
Contributor

(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!)

AndrewGMorgan added a commit to AndrewGMorgan/libcap_mirror that referenced this issue Oct 30, 2022
It took me a while to figure out why optimized C compilation seemed
to generate miscomputation of the Fibonacci number sequence. It appears
to be an unresolved issue with Go's internal linking which is discussed
here:

  golang/go#24321

For a compute kernel, it seems important to be able to accommodate
compiler optimization. This adds some refinement for the strategy
I'm exploring to address:

  https://bugzilla.kernel.org/show_bug.cgi?id=216610

Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants