Re: Possible reloc patch (2/2)

[Richard Sandiford <rsandifo at cygnus dot com>]

> I think the basic issue is that cgen-based gas/binutils ports should
> in general not use the common relocations (BFD_RELOC_32 and its
> R_ ilk), especially for instruction operands.  Adding a new relocation
> type is quite routine, and should be preferred, almost always.

But if you have a 32-bit absolute address and BFD_RELOC_32 does what you
want, why create another reloc with identical behaviour?

From the replies I've got, it seems to be generally accepted that having
relocs point to the start of instructions is better than having them point
to the start of operands.  I'm just confused as to why.  If a 32-bit
address can occur at more than one place in an instruction, what do you
gain by defining different relocs for each instruction format, rather than
one that applies to the operand itself?  My intuition behind a "reloc" was
that it described a bit sequence that needed adjusting; that whether the
bit sequence was part of an instruction or part of data wasn't really
relevant.

> With respect to your specific approach, it is possible to accomplish
> the same goal outside cgen, that is, without marking up the operands
> with attributes, by intercepting the usual complement of hooks, such
> as md_cgen_lookup_reloc in gas, *_relocate_section in bfd.

I can see how it's possible to accomplish the same goal if you create a
separate reloc for each operand.  All I was trying to do was cut down the
work involved where the same sort of relocation may be needed at more than
one place within an instruction.

Richard