Home Original page

[BUG?] GCC 4.5.2 produces deprecated ARM relocation

Nick Clifton nickc@redhat.com
Thu Oct 27 11:20:00 GMT 2011 
Hi Matt,

>> + for (i = 0; i< ARRAY_SIZE (reloc_names); i++)
>> + {
>> + struct reloc_entry * entry = reloc_names + i;
>> +
>> + if (arm_is_eabi()&& entry->reloc == BFD_RELOC_ARM_PLT32)
>> + /* This makes encode_branch() use the EABI versions of this
>> relocation. */
>> + entry->reloc = BFD_RELOC_UNUSED;
>> +
>> + hash_insert (arm_reloc_hsh, entry->name, (void *) entry);
>> + }
>
> While this is probably the simplest way to fix this in terms of code
> change I wonder whether it would be better to actually modify the
> encode_branch function?

I thought about that, but it is less efficient.  It means testing 
arm_is_eabi() on every call to encode_branch() even though the abi 
setting cannot be changed once assembly has started.

> This also then allows us to ensure that the BFD_RELOC_ARM_* value in
> default_reloc really maps to R_ARM_CALL or R_ARM_JUMP24 as the
> documentation says :-).

But they do with my patch.  Using BFD_RELOC_UNUSED means that 
inst.operands[0].hasreloc will be FALSE and so the default reloc (CALL 
or JUMP24) will be used.

> I'm also concerned at else will happen if we stop marking these
> relocations as BFD_RELOC_ARM_PLT32.

I think that we do need to make this change - or something like it - 
ARM_PLT32 is deprecated and we should stop using it for EABI targets.

> For instance in arm_fix_adjustable
> there is code to not allow symbols to be discarded on GOT related relocs
> which depends on this relocation type.

That looks like a potential bug in arm_fix_adjustable() to me.  I could 
extend my patch to include ARM_CALL and ARM_JUMP24 in the list of 
relocations which preserve symbols.


Cheers
   Nick
More information about the Binutils mailing list