For an absolute address relocation in C objects (e.g.
R_X86_64_64), we turn it into an R_ADDR relocation and handle it
the same way. For internal linking PIE, this R_ADDR relocation
cannot be resolved statically. We need to generate a dynamic
relocation for it. This CL makes it so.
This fixes internal linking PIE on the dev.boringcrypto branch.
Test will be enabled in the next CL.
Change-Id: I9bdd6517ccd79cbbe9c64844a31536bf3da37616
Reviewed-on: https://go-review.googlesource.com/c/go/+/218837
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ld.Errorf(s, "unexpected R_X86_64_64 relocation for dynamic symbol %s", targ.Name)
}
r.Type = objabi.R_ADDR
+ if ctxt.BuildMode == ld.BuildModePIE && ctxt.LinkMode == ld.LinkInternal {
+ // For internal linking PIE, this R_ADDR relocation cannot
+ // be resolved statically. We need to generate a dynamic
+ // relocation. Let the code below handle it.
+ break
+ }
return true
// Handle relocations found in Mach-O object files.
ld.Errorf(s, "unexpected R_AARCH64_ABS64 relocation for dynamic symbol %s", targ.Name)
}
r.Type = objabi.R_ADDR
+ if ctxt.BuildMode == ld.BuildModePIE && ctxt.LinkMode == ld.LinkInternal {
+ // For internal linking PIE, this R_ADDR relocation cannot
+ // be resolved statically. We need to generate a dynamic
+ // relocation. Let the code below handle it.
+ break
+ }
return true
case objabi.ElfRelocOffset + objabi.RelocType(elf.R_AARCH64_LDST8_ABS_LO12_NC):