Should we use R_ARM_MOVT_PREL for ARM PIC?

[Rafael Espíndola via llvm-commits]

On 21 June 2016 at 06:18, Peter Smith <peter.smith at linaro.org> wrote:
> Hello Rafael,
>
> I don't have a particular good answer for why there is a difference in
> code-generation right now.

Do you think it would be profitable to use movw+movt? Should I open a
bug about it?

> With respect to the relocations, I think there might already be
> movw/movt relocations that can do some of what you want.
> The base relative versions of the relocations are:
> R_ARM_MOVT_BREL
> R_ARM_MOVW_BREL
> R_ARM_MOVW_BREL_NC
> R_ARM_THM_MOVT_BREL
> R_ARM_THM_MOVW_BREL
> R_ARM_THM_MOVW_BREL_NC
>
> These are all of the form ((S + A) | T) – B(S)
>
> where B(S) is defined as:
>
> B(S) is the addressing origin of the output segment defining the
> symbol S. The origin is not required to be the base address of the
> segment. This value must always be word-aligned.
>
> The wording of B(S) is vague enough for platforms such as Linux to say
> what the addressing origin of B(S). It could be defined in terms of
> the GOT.

It doesn't seem to be implemented like that in gold.

> If you've got something different in mind and want to make a proposal
> for a new relocation type the ABI documents have an email address on
> the front of the document that can be used.
>
> Link to ARM ELF for convenience:
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

Nah, it is just a passing curiosity.

I am refactoring the pic/preemption code and noticed that ELF codegen
avoids using movw/movt when MachO is able to. If it was easy I would
change it to use it, but adding to the ABI would be an yak too many
:-)

Cheers,
Rafael