This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86-64: always use unsigned 32-bit relocation for 32-bit addressing


>>> On 13.11.17 at 16:44, <hjl.tools@gmail.com> wrote:
> On Mon, Nov 13, 2017 at 6:30 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 13.11.17 at 14:35, <hjl.tools@gmail.com> wrote:
>>> On Mon, Nov 13, 2017 at 3:50 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> Except for %eip-relative addressing, where we don't have a suitable
>>>> relocation type silently wrapping at the 4G boundary, consistently
>>>> force use of R_X86_64_32 (in ELF terms) instead of its sign-extending
>>>> counterpart. This wasn't right in case there was no base register in
>>>> the addressing expression.
>>>
>>> Since displacement is signed, won't it generate different code?  Is there
>>> a bug report to show it is necessary?
>>
>> I'm afraid I don't understand the question: Signed-ness of
>> 32-bit quantities doesn't matter when talking of 32-bit addressing.
>> If you think something is wrong here, may I ask that you take the
>> tests being added and state what you would want to see be the
>> expected result(s)?
>>
> 
> We currently have
> 
> (BASE + INDEX * SCALE + DISP) & 0xffffffff
> 
> You want to change it to
> 
> (BASE + INDEX * SCALE + (DISP & 0xffffffff)) & 0xffffffff
> 
> Am I correct?

Yes, that's a way to put it. And it's another way to show that
there's no dependency on the sign bit here. IOW I still don't
see how you would see different (as in: wrong) code to be
generated. The point of the change merely is to prevent
overflow errors from the linker when processing relocations,
which signed relocations could trigger, but unsigned ones
can't (unless the target is above 4Gb of course).

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]