This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ix86 targets without BFD64
>>> On 23.10.17 at 23:25, <hjl.tools@gmail.com> wrote:
> On Mon, Oct 23, 2017 at 5:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Oct 23, 2017 at 5:11 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 23.10.17 at 13:13, <hjl.tools@gmail.com> wrote:
>>>> On Sun, Oct 22, 2017 at 11:53 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> Hello,
>>>>>
>>>>> there being quite a few BFD64 conditionals in tc-i386.c, I would
>>>>> conclude that things are supposed to work fine when doing a
>>>>> purely 32-bit build (which happen to result when I cross build on
>>>>> cygwin, but of course by not forcing --enable-64-bit-bfd I can
>>>>> also see this on a native Linux build on a 32-bit distro). Yet each of
>>>>> the last two lines of
>>>>>
>>>>> .text
>>>>> _start:
>>>>> mov 0x87654321, %eax
>>>>> mov $0x87654321, %eax
>>>>>
>>>>> .code64
>>>>> movabs 0x87654321, %al
>>>>> movabs $0x87654321, %rax
>>>>>
>>>>> trigger the abort() in offset_in_range(). Since the chosen target
>>>>> automatically enables elf32_x86_64, the solution can't possibly be
>>>>> to disallow .code64 in such a build. All other alternatives I can
>>>>> think of would, however, appear to require a full audit of all 64-bit
>>>>> immediate / displacement processing in order to make sure all valid
>>>>> code (i.e. anything not requiring 64-bit relocations) is accepted.
>>>>>
>>>>> Thoughts?
>>>>
>>>> We can disable elf32_x86_64 and disallow .code64 if bfd_vma is 32 bit.
>>>
>>> Hmm, interesting. Then why was it added there in the first place?
>
> elf32_x86_64 is added by
>
> targ_extra_libpath=elf32_x86_64
>
> Since elf64-x86-64.o isn't compiled in, elf32_x86_64 never worked.
>
>>>
>>
>> Since my i386 binutils is built with 64-bit BFD, it isn't a problem.
>> BTW, I don't believe elf32_x86_64 linker works correctly with 32-bit
>> BFD.
>>
>
> I am going to check in this patch.
Thanks, looks good as a minimal fix (fwiw).
Jan