Re: PATCH: Check invalid x32 relocations.

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 17, 2011 at 6:22 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>> On 17.01.11 at 15:13, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Mon, Jan 17, 2011 at 6:01 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>> On 17.01.11 at 13:42, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>> On Mon, Jan 17, 2011 at 1:49 AM, Jan Beulich <JBeulich@novell.com> wrote:
>>>>>>>> On 15.01.11 at 16:50, "H.J. Lu" <hongjiu.lu@intel.com> wrote:
>>>>>> --- a/bfd/elf64-x86-64.c
>>>>>> +++ b/bfd/elf64-x86-64.c
>>>>>> @@ -1179,6 +1179,39 @@ elf_x86_64_check_relocs (bfd *abfd, struct
>>>>>> bfd_link_info *info,
>>>>>> ? ? ? ? ? h = (struct elf_link_hash_entry *) h->root.u.i.link;
>>>>>> ? ? ? }
>>>>>>
>>>>>> + ? ? ?/* Check invalid x32 relocations. ?*/
>>>>>> + ? ? ?if (!ABI_64_P (abfd))
>>>>>> + ? ? switch (r_type)
>>>>>> + ? ? ? {
>>>>>> + ? ? ? default:
>>>>>> + ? ? ? ? break;
>>>>>> +
>>>>>> + ? ? ? case R_X86_64_64:
>>>>>
>>>>> While I buy that all the below ones are meaningless, excluding
>>>>> the one above seems questionable (and exposes one further
>>>>> reason why tying the ABI to object file format is bogus). An
>>>>> obvious use case is to initialize a 64-bit variable with a constant
>>>>> defined in another object.
>>>>>
>>>>
>>>> Show me how to initialize a 64-bit variable with a constant
>>>> defined in another object in x32 format in assembly code.
>>>> I will check it as a testcase.
>>>
>>> Source1:
>>> ? ? ? ?.text
>>> ? ? ? ?.global _start
>>> _start:
>>> ? ? ? ?ret
>>>
>>> ? ? ? ?.data
>>> var: ? ?.quad ? cnst
>>
>> [hjl@gnu-4 tmp]$ cat x.s
>> Source1:
>> ? ? ? ?.text
>> ? ? ? ?.global _start
>> _start:
>> ? ? ? ?ret
>>
>> ? ? ? ?.data
>> var: ? ?.quad ? cnst
>> [hjl@gnu-4 tmp]$ as --x32 -o x.o x.s
>> x.s: Assembler messages:
>> x.s:8: Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
>
> That is what I was complaining about,

This message doesn't come from my elf64-x86-64.c change.

>> [hjl@gnu-4 tmp]$
>>
>>> Source2:
>>> ? ? ? ?.global cnst
>>> .equ ? ?cnst, 0x12345678
>>
>> [hjl@gnu-4 tmp]$ cat y.s
>> ? ? ? ?.global cnst
>> .equ ? ?cnst, 0x123456789abce
>> [hjl@gnu-4 tmp]$ as --x32 -o y.o y.s
>> [hjl@gnu-4 tmp]$ nm y.o
>> 6789abce A cnst
>
> ..., while that is because you force use of 32-bit ELF. And it
> certainly seems bogus that there's not even a warning.

There should be an error for both --x32 and --32.  Patch
is welcome.

>> [hjl@gnu-4 tmp]$
>>
>> The problem is cnst can only be 32bit. ".quad cnst" isn't needed. ?You can
>> use
>>
>> ? ? ?.long cnst
>> ? ? ?.long 0
>>
>> if you really want 64bit value for a 32bit addres.
>
> If I control the directive, I could do so. If, however, the directive
> gets produced by a compiler, I can't (and depend on either the
> compiler doing the conversion for me, or a suitable relocation to
> be available).

32bit compilers shouldn't use .quad for address. If it does, it
is a compiler bug.

-- 
H.J.