[llvm-dev] Proposal: arbitrary relocations in constant global initializers

[Peter Collingbourne via llvm-dev]

On Wed, Aug 26, 2015 at 11:49:46AM -0400, Rafael Espíndola wrote:
> This is pr10368.
> 
> Do we really need to support hard coded relocation numbers? Looks like
> the examples above have a representation as constant expressions:
> 
>  (sub (add (ptrtoint @foo)  0xeafffffe) cur_pos)
> 
> no?

I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation
on ARM has specific semantics to implement ARM/Thumb interworking; see
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
Note that R_ARM_CALL has the same operation but different semantics.
I suppose that we could try looking at the addend to decide which relocation
to use, but this would mean adding more complexity to the assembler (along
with any pattern matching that would need to be done). It seems simpler,
both conceptually and in the implementation, for the client to directly say
what it wants in the object file.

There's also the point that if @foo is defined outside the current linkage
unit, or refers to a Thumb function, the above expression in a constant
initializer would refer to the function's PLT entry or a shim, but in a
function it would refer to the function's actual address, so the evaluation
of this expression would depend on whether it was constant folded. (Although
on the other hand we might just declare that by using such a constant in a
global initializer that may be constant folded the client is asserting that
it doesn't care which address is used.)

> Why do you need to be able to avoid them showing up in function
> bodies? It would be unusual but valid to pass the above value as an
> argument to a function.

This was part of the proposal mainly for the constant folding reasons mentioned
above, but if we did go with a reloc expression we'd need to encode the
original constant address in the reloc for PC-relative expressions, which
wouldn't be necessary if we disallow it.

Thanks,
-- 
Peter