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

[Rafael Espíndola via llvm-dev]

> 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.)

I am pretty sure there is use for some target specific expressions, my
concerns are
* Using a target specific expression when it could be represented in a
target independent way (possibly a bit more verbose).
* Using the raw relocation values, instead of something like
thumb_addr_delta. With this the semantics of each constant expression
are still documented in the language reference.

>> 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.

Seems better to make it explicit IMHO.

BTW, about the assembly change: Please check what the binutils guys
think of it. We do have extensions, but it is nice to at least let
them know so that we don't end up with two independent solutions in
the future.

Cheers,
Rafael