From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30379 invoked by alias); 12 Aug 2011 17:53:57 -0000 Received: (qmail 30326 invoked by uid 22791); 12 Aug 2011 17:53:55 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Aug 2011 17:53:33 +0000 Received: by qwh5 with SMTP id 5so1876737qwh.20 for ; Fri, 12 Aug 2011 10:53:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.32.82 with SMTP id b18mr840973qcd.123.1313171612683; Fri, 12 Aug 2011 10:53:32 -0700 (PDT) Received: by 10.229.29.7 with HTTP; Fri, 12 Aug 2011 10:53:32 -0700 (PDT) In-Reply-To: References: <4E44F2CF0200007800050EDE@nat28.tlf.novell.com> <4E4543F70200007800050FC6@nat28.tlf.novell.com> <4E454DE6020000780005100E@nat28.tlf.novell.com> <4E4557DB0200007800051054@nat28.tlf.novell.com> <4E4560370200007800051095@nat28.tlf.novell.com> Date: Fri, 12 Aug 2011 17:53:00 -0000 Message-ID: Subject: Re: [x32] Allow R_X86_64_64 From: "H.J. Lu" To: Jan Beulich Cc: GCC Development , x32-abi@googlegroups.com, Binutils Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00256.txt.bz2 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 wrot= e: >>>>>>> On 12.08.11 at 16:02, "H.J. Lu" wrote: >>>>> On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wr= ote: >>>>>>>>> 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 w= rote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> It turns out that x32 needs R_X86_64_64. =A0One major reason is >>>>>>>>>>>> the displacement range of x32 is -2G to +2G. =A0It isn't a pro= blem >>>>>>>>>>>> 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. =A0I am checking the follow pa= tch >>>>>>>>>>>> into x32 psABI to allow R_X86_64_64. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> X32 =A0Linker should treats R_X86_64_64 as R_X86_64_32 >>>>>>>>>>> zero-extended to 64bit for output. =A0I will update x32 psABI w= ith >>>>>>>>>> >>>>>>>>>> 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 >>>> >>>> =A0 =A0 =A0 =A0.equ =A0 =A0sym, 0x1234567890 >>>> =A0 =A0 =A0 =A0.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: >>> =A0 =A0Num: =A0 =A0Value =A0Size Type =A0 =A0Bind =A0 Vis =A0 =A0 =A0Nd= x Name >>> =A0 =A0 =A00: 00000000 =A0 =A0 0 NOTYPE =A0LOCAL =A0DEFAULT =A0UND >>> =A0 =A0 =A01: 00000000 =A0 =A0 0 SECTION LOCAL =A0DEFAULT =A0 =A01 >>> =A0 =A0 =A02: 00000000 =A0 =A0 0 SECTION LOCAL =A0DEFAULT =A0 =A02 >>> =A0 =A0 =A03: 00000000 =A0 =A0 0 SECTION LOCAL =A0DEFAULT =A0 =A03 >>> =A0 =A0 =A04: 34567890 =A0 =A0 0 NOTYPE =A0GLOBAL DEFAULT =A0ABS 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. --=20 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