cmd/internal/obj/x86: JMP $sym generates PCREL relocation, not CALL #10690
Comments
|
/cc @ianlancetaylor for awful things |
|
I already sent this to him on IRC :) Another awful thing would be to only emit R_CALL in this situation when -dynlink is passed to 6g, which is still awful but is also at least local and would let me get on with my life. |
|
Seems to me that an R_PCREL from Go code to a function defined in another shared library should add a PLT entry and jump to that. That's what an ELF linker does: a PC-relative reference to an STT_FUNC defined in a shared library will build a PLT entry and refer to that. |
|
Ah OK. Doesn't sound too hard. Of course we don't currently record the STT_xxx anywhere when reading symbols out of a shared library but that's fixable (and probably let's us de-special snowflake tlsg handling, come to think of it...). |
|
CL https://golang.org/cl/9711 mentions this issue. |
…ibrary An ELF linker handles a PC-relative reference to an STT_FUNC defined in a shared library by building a PLT entry and referring to that, so do the same in 6l. Fixes golang#10690 Change-Id: I061a96fd4400d957e301d0ac86760ce256910e1d
…ibrary An ELF linker handles a PC-relative reference to an STT_FUNC defined in a shared library by building a PLT entry and referring to that, so do the same in 6l. Fixes golang#10690 Change-Id: I061a96fd4400d957e301d0ac86760ce256910e1d
If you build the standard library into a shared object, and try and put something like "type B struct { bufio.Writer }" into another shared library, linking fails with complaints about a R_X86_64_PC32 relocation to an undefined symbol. This turns out to be down to the wrapper methods, and basically it's because the tail call in the wrapper method ends up producing a JMP to the real implementation and a R_PCREL reloc to fill this in. This doesn't work when the real implementation is in a separate shared object.
The obvious fix -- emitting a R_CALL reloc -- fixes this problem, but then ./test/nosplit.go fails because now the stack check machinery in the linker thinks a JMP instruction consumes a word of stack (because it assumes a R_CALL indicates a call).
Not sure what to do. An R_JMP relocation? Sounds awful. Handling a R_PCREL against an undefined symbol as if it was an R_CALL? Also sounds awful. Having the stack check code disassemble the code to figure out if it's a call or a jump? Sounds really awful.
The text was updated successfully, but these errors were encountered: