Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation

[Nick Clifton <nickc at redhat dot com>]

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