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: Check invalid x32 relocations.


>>> 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,

> [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.

> [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).

Jan


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