This is the mail archive of the 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: [BUG?] GCC 4.5.2 produces deprecated ARM relocation

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

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