From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: GCC Development <gcc@gcc.gnu.org>,
x32-abi@googlegroups.com, Binutils <binutils@sourceware.org>
Subject: Re: [x32] Allow R_X86_64_64
Date: Fri, 12 Aug 2011 14:03:00 -0000 [thread overview]
Message-ID: <CAMe9rOqaDdL0vr4DDRQT6idawELJAvRbvD-isEEcLGue2BHUvg@mail.gmail.com> (raw)
In-Reply-To: <4E454DE6020000780005100E@nat28.tlf.novell.com>
On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 12.08.11 at 15:22, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> On 12.08.11 at 14:09, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>> On 12.08.11 at 06:37, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu <hjl.tools@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.
>>>
>>
>> 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?
--
H.J.
next prev parent reply other threads:[~2011-08-12 14:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-01 22:16 H.J. Lu
2011-08-12 4:37 ` H.J. Lu
2011-08-12 7:30 ` Jan Beulich
2011-08-12 12:10 ` H.J. Lu
2011-08-12 13:16 ` Jan Beulich
2011-08-12 13:22 ` H.J. Lu
2011-08-12 13:58 ` Jan Beulich
2011-08-12 14:03 ` H.J. Lu [this message]
[not found] ` <4E4557DB0200007800051054@nat28.tlf.novell.com>
[not found] ` <CAMe9rOrTw_R2U+9HeNY6iGhd6RD6ADG1Z9tjP8GyXGevnqSsQg@mail.gmail.com>
[not found] ` <4E4560370200007800051095@nat28.tlf.novell.com>
2011-08-12 15:52 ` H.J. Lu
2011-08-12 17:53 ` H.J. Lu
2011-08-12 19:59 ` H.J. Lu
2011-08-15 6:29 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMe9rOqaDdL0vr4DDRQT6idawELJAvRbvD-isEEcLGue2BHUvg@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=JBeulich@novell.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=x32-abi@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).