https://sourceware.org/bugzilla/show_bug.cgi?id=20427
Ali Bahrami <ali_swbugzilla at emvision dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ali_swbugzilla at emvision dot com --- Comment #7 from Ali Bahrami <ali_swbugzilla at emvision dot com> --- We think it's not a linker bug. The 32 and 64-bit sparc platform ABIs are distinct, and here, we're talking about relocations defined for 64-bit objects, but not for 32-bit ones. The error from ld seems legit, and is intended to catch this case. The 2 tables of sparc relocations (32 and 64-bit) can be found here: https://docs.oracle.com/cd/E53394_01/html/E54813/chapter6-54839.html#OSLLGchapter6-62988 This question wouldn't come up if we were discussing x86, where the 32 and 64-bit relocations are pretty different, but with sparc, where the 64-bit case is essentially an extension of the 32-bit case, that's probably less obvious. Just to be sure, I checked with our resident sparc architecture expert, and he told us: I'm not exactly sure what the question is. The relocations are for late binding of the value of a symbol. Symbol values in a 32-bit program cannot be larger than 32-bits, AFAIK. Now relocations are a little more complicated, because they encode an expression. So, we could have relocations that encode an expression that is larger than 32-bits for a 32-bit program. But there has been no need for them, so they were never created, AFAIK. It would certainly be possible to create some 64-bit relocation expressions for 32-bit programs. I would want to see some better justification before creating them, though. And some assembler syntax might be necessary to disambiguate which relocation should be used in some circumstances. Which I will simplify to "we haven't needed that relocation for 32-bit sparc, so it doesn't exist". Another engineer here mentioned the following: For what it's worth, Go's internal linker handles this by generating two relocations internally -- one for the lower half of the 64-bit value and one for the upper half of the 64-bit value. This tends to work out nicely since you have to load each half separately anyway: // R_ADDRSPARC64LO (only used on sparc64) resolves to low 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64LO // R_ADDRSPARC64HI (only used on sparc64) resolves to high 32bits of a // 64-bit address, by loading the address into a register with two instructions. R_ADDRSPARC64HI That squares with Nick's earlier comment Does it, for example, produce two 32-bit relocs, one for the lower 32-bits and one for the upper 32-bits ? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils