On Fri, Aug 12, 2011 at 10:53 AM, H.J. Lu wrote: > On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu wrote: >> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote: >>>>>> On 12.08.11 at 16:47, "H.J. Lu" wrote: >>>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote: >>>>>>>> On 12.08.11 at 16:02, "H.J. Lu" wrote: >>>>>> On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote: >>>>>>>>>> On 12.08.11 at 15:22, "H.J. Lu" wrote: >>>>>>>> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: >>>>>>>>>>>> On 12.08.11 at 14:09, "H.J. Lu" wrote: >>>>>>>>>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: >>>>>>>>>>>>>> On 12.08.11 at 06:37, "H.J. Lu" wrote: >>>>>>>>>>>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu 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. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, it should work just fine for x32 by zero-extending 32bit >>>>>>>> address to 64bit. >>>>>>> >>>>>>> For a constant that has more than 32 significant bits??? >>>>>>> >>>>>> >>>>>> Can you give me an example in assembly code? >>>>> >>>>> Something like >>>>> >>>>>        .equ    sym, 0x1234567890 >>>>>        .global sym >>>>> >>>> >>>> "sym" is truncated to 32bit: >>> >>> Yes, because of your tying of the ABI to ELF32. >> >> X32 uses ELF32 and won't change. >> >>>> Symbol table '.symtab' contains 5 entries: >>>>    Num:    Value  Size Type    Bind   Vis      Ndx Name >>>>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND >>>>      1: 00000000     0 SECTION LOCAL  DEFAULT    1 >>>>      2: 00000000     0 SECTION LOCAL  DEFAULT    2 >>>>      3: 00000000     0 SECTION LOCAL  DEFAULT    3 >>>>      4: 34567890     0 NOTYPE  GLOBAL DEFAULT  ABS sym >>>> >>>> However, one can write >>>> >>>> .quad main + 0x8000000 >>> >>> And I suppose that wouldn't work either with your R_X86_64_64 >>> implied zero-extension... >>> >> > > I will add R_X86_64_64 support to x32 dynamic linker.  I will > also add R_X86_64_RELATIVE64 to x32 dynamic linker. > > For R_X86_64_64 relocation, if addend is 0, linker will > turn it to R_X86_64_32 and zero-extends it to 64bit. Otherwise, > linker will generate R_X86_64_RELATIVE64 if it is a relocation > against a local symbol or keep R_X86_64_64 for relocations > against external symbols. We need R_X86_64_RELATIVE64 > since R_X86_64_RELATIVE only updates 32bit destination. > > > -- > H.J. > --- > diff --git a/object-files.tex b/object-files.tex > index 7f0fd14..d2be264 100644 > --- a/object-files.tex > +++ b/object-files.tex > @@ -483,10 +483,13 @@ or \texttt{Elf32_Rel} relocation. >       \texttt{R_X86_64_TLSDESC_CALL} & 35 & none &  \\ >       \texttt{R_X86_64_TLSDESC} & 36 & \textit{word64}$\times 2$ & \\ >       \texttt{R_X86_64_IRELATIVE} & 37 & \textit{wordclass} & > \texttt{indirect (B + A)}\\ > +      \texttt{R_X86_64_RELATIVE64} $^{\dagger\dagger}$ & 38 & > \textit{word64} & \texttt{B + A} \\ >  %      \texttt{R_X86_64_GOT64} & 16 & \textit{word64} & \texttt{G + A} \\ >  %      \texttt{R_X86_64_PLT64} & 17 & \textit{word64} & \texttt{L + A - P} \\ >      \cline{1-4} >     \multicolumn{3}{l}{\small $^\dagger$ This relocation is used only > for LP64.}\\ > +    \multicolumn{3}{l}{\small $^{\dagger\dagger}$ This relocation only > +    appears in X32 executable files or shared objects.}\\ >     \end{tabular} >   \end{center} >  \Hrule > I checked the enclosed linker change. I also enclosed the glibc change to handle R_X86_64_RELATIVE64 and R_X86_64_64 for x32. -- H.J.