From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30888 invoked by alias); 12 Aug 2011 07:30:17 -0000 Received: (qmail 30870 invoked by uid 22791); 12 Aug 2011 07:30:13 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Aug 2011 07:29:59 +0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Fri, 12 Aug 2011 08:30:55 +0100 Message-Id: <4E44F2CF0200007800050EDE@nat28.tlf.novell.com> Date: Fri, 12 Aug 2011 07:30:00 -0000 From: "Jan Beulich" To: "H.J. Lu" Cc: "GCC Development" ,, "Binutils" Subject: Re: [x32] Allow R_X86_64_64 References: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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/msg00239.txt.bz2 >>> 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. >> >> >=20 > 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. Jan > --- > diff --git a/object-files.tex b/object-files.tex > index 7f0fd14..d1543b5 100644 > --- a/object-files.tex > +++ b/object-files.tex > @@ -451,7 +451,7 @@ or \texttt{Elf32_Rel} relocation. > \multicolumn{1}{c}{Calculation} \\ > \hline > \texttt{R_X86_64_NONE} & 0 & none & none \\ > - \texttt{R_X86_64_64} & 1 & \textit{word64} & \texttt{S + A} \\ > + \texttt{R_X86_64_64} $^{\dagger\dagger}$ & 1 & \textit{word64} > & \texttt{S + A} \\ > \texttt{R_X86_64_PC32} & 2 & \textit{word32} & \texttt{S + A - P}= \\ > \texttt{R_X86_64_GOT32} & 3 & \textit{word32} & \texttt{G + A} \\ > \texttt{R_X86_64_PLT32} & 4 & \textit{word32} & \texttt{L + A - P}= \\ > @@ -487,6 +487,8 @@ or \texttt{Elf32_Rel} relocation. > % \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 relocatable files for X32.}\\ > \end{tabular} > \end{center} > \Hrule > ---- >=20 > I opened: >=20 > http://sourceware.org/bugzilla/show_bug.cgi?id=3D13082=20 >=20 > and will fix it. >=20