sh-elf: the substraction of two symbols

[Ian Lance Taylor]

Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:

> A comment from Ian, the original author, would be appreciated,
> at least on the historical reasons why in sh-elf partial_inplace
> is true for all other "real" relocations, and sh-elf still being
> RELA.

I would like to say that there is a good reason, but there probably
isn't one.  I think I just threw the SH ELF support together in a
couple of days for some reason.  There was no spec for it.  Relocation
handling is so screwed up in gas that it's easier to just go with the
flow than it is to get it to do the right thing.  Since I was making
up SH ELF anyhow, I think I just made the relocations COFF-like, since
that is what the assembler was generating.

I had to use RELA relocations to make the relaxation work.  I needed a
place to store the additional information.  In COFF, the relocations
have an r_offset field which I used for the extra information.  The
COFF SH relocation entries are 16 bytes, as opposed to say COFF i386
in which the relocation entries are 10 bytes.

> If the src_mask had been 0xffffffff for R_SH_REL32, the theory
> of the partial_inplace unintentionally being false would be more
> probable.  I believe we shouldn't change the semantics of
> R_SH_REL32; we should correct the bugs.  If we change the
> semantics, old code will need to be re-assembled, so I can't
> approve the patch as-is.  If semantics are *not* changed despite
> the appearance of the patch, a large comment is needed (which I
> think it is anyway, to explain why partial_inplace is false for
> R_SH_REL32).

Yeah, I wouldn't change the semantics unless there is some incredibly
good reason, like somebody else wrote a spec that defines things
differently.

Ian