>>> On 12.08.11 at 14:09, "H.J. Lu" <hjl.to...@gmail.com> wrote: > On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich <jbeul...@novell.com> wrote: >>>>> On 12.08.11 at 06:37, "H.J. Lu" <hjl.to...@gmail.com> wrote: >>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>> Hi, >>>> >>>> It turns out that x32 needs R_X86_64_64. One major reason is >>>> the displacement range of x32 is -2G to +2G. It isn't a problem >>>> for compiler since only small model is required for x32. >>>> >>>> However, to address 0 to 4G directly in assembly code, we have >>>> to use R_X86_64_64 with movabs. I am checking the follow patch >>>> into x32 psABI to allow R_X86_64_64. >>>> >>>> >>> >>> X32 Linker should treats R_X86_64_64 as R_X86_64_32 >>> zero-extended to 64bit for output. I will update x32 psABI with >> >> I'm sorry to say that, but the situation about x32 seems to be >> getting worse with each change you do, every time again >> revolving around mixing up ABI specification and a particular >> implementation thereof. >> >> Here, if you need something zero-extended (though I can't see >> why you would), then you should use a new relocation type. As >> pointed out before, there are valid possible uses of R_X86_64_64 >> that would require the semantics of x86-64. >> > > When does x32 need the semantics of x86-64 for R_X86_64_64?
When referencing an assembler or linker defined constant that exceeds 32-bit in width. Given that this is a 64-bit architecture with 32-bit addresses, at least I would expect such to work. > No, you can't mix ELF32 with ELF64. That wasn't the question, but clearly your tying of x32 to ELF32 is another limitation that makes such assembler defined constants not work (not sure about linker script defined ones). Jan
