<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 7, 2016 at 2:48 PM, Evgenii Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Fri, Oct 7, 2016 at 2:28 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
> On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
>> wrote:<br>
>> > On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov<br>
>> > <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>> >><br>
>> >> I've tried implementing some of the alternatives mentioned in this<br>
>> >> thread, and so far I like this syntax the most:<br>
>> >><br>
>> >> i32 reloc (29, void ()* @f, 3925868544)<br>
>> >> ; 29 = 0x1d = R_ARM_JUMP24<br>
>> >> ; 3925868544 = 0xea000000<br>
>> >><br>
>> >> Note the zeroes in the relocated data instead of 0xfffffe in the<br>
>> >> original proposal. This is aligned with the way LLVM emits relocations<br>
>> >> in the backend, and avoids encoding the addend in a<br>
>> >> relocation-specific way in the IR.<br>
>> ><br>
>> ><br>
>> > I am confused by this statement. If the zeros aren't what appear in the<br>
>> > object file, it seems rather relocation specific to me.<br>
>><br>
>> These bytes will always be zeroes, which makes them not relocation<br>
>> specific.<br>
>> Object file contents, on the other hand, are relocation specific. In<br>
>> particular the constant 0xfffffe is ARM_JUMP24 encoding for zero<br>
>> offset (from the start of the current instruction).<br>
>><br>
>> Somehow I find this IR representation very natural - you've got data<br>
>> bytes for anything that's not relocated, and the target expression<br>
>> (possibly including addend).<br>
><br>
><br>
> My point is that the addend mangling between the IR and the object file<br>
> would be relocation specific.<br>
><br>
> What happens if I want to start using some new type of relocation? Will I<br>
> need to teach the MC layer about it?<br>
<br>
</div></div>Yes. MC needs to know if it is pc-relative or not, at least.</blockquote><div><br></div><div>Why?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's<br>
the benefit in bypassing MC completely?<br></blockquote><div><br></div><div>To reduce complexity. Rather than teaching MC about every relocation to be used with reloc, you can just teach the component that produces the reloc.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5">
><br>
>> ><br>
>> >><br>
>> >> Instead, the addend can be<br>
>> >> specified in the second argument with the regular IR expressions, like<br>
>> >> the following:<br>
>> >><br>
>> >> @w = internal global [3 x i32]<br>
>> >>    [i32 reloc (29, void ()* @f, 3925868544),<br>
>> >>     i32 reloc (29, [3 x i32]* @w, 3925868544),<br>
>> >>     i32 reloc (29, i32* getelementptr (i32, i32* bitcast ([3 x i32]*<br>
>> >> @w to i32*), i32 1), 3925868544)<br>
>> >> ], align 4<br>
>> >><br>
>> >><br>
>> >><br>
>> >> we also get relocations for elements 1 and 2 of @w optimized out for<br>
>> >><br>
>> >> free. If the "addend" (i.e. the third arg of reloc) was specified as<br>
>> >><br>
>> >> 0xeafffffe, the backend would have had to decode this value first.<br>
>> ><br>
>> ><br>
>> > I think it may be ok to allow non-global constants as the second operand<br>
>> > (the utility of this feature being the ability to freely RAUW a global<br>
>> > without worrying about reloc constants).<br>
>> ><br>
>> > This doesn't necessarily need to act as an alternative means of<br>
>> > specifying<br>
>> > an addend, though. Instead, the backend could synthesise local symbols<br>
>> > to<br>
>> > act as relocation targets. For example, your example would conceptually<br>
>> > translate to:<br>
>> ><br>
>> > @w = internal global [3 x i32]<br>
>> >    [i32 reloc (29, void ()* @f, 3925868544),<br>
>> >     i32 reloc (29, [3 x i32]* @w, 3925868544),<br>
>> >     i32 reloc (29, i32* @dummy, i32 1), 3925868544)<br>
>> ><br>
>> > @dummy = internal alias i32* getelementptr (i32, i32* bitcast ([3 x<br>
>> > i32]* @w<br>
>> > to i32*), i32 1)<br>
>> ><br>
>> > This way, you save yourself from needing to worry about manipulating<br>
>> > addends<br>
>> > in the backend, the linker will take care of it for you.<br>
>><br>
>> That's no worry at all, AsmPrinter::lowerConstant evaluates both<br>
>> constant expressions to MCExpr: w + 4.<br>
><br>
><br>
> But you still need to worry about how "w + 4" is represented in the object<br>
> file.<br>
<br>
</div></div>It's a relocation with target "w" and addend "4".<br></blockquote><div><br></div><div>Someone needs to implement how to apply the addend 4 to the addend 0xea000000. That's what I meant by manipulating addends. You could do that by relying on MC to do it (your proposal), or you can rely on the linker to do it (my proposal).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
With my proposal, the frontend/middleend controls section data<br>
indirectly, meaning the actual final section data does not appear as<br>
an IR constant, but we can still get whatever constant we want. On the<br>
other hand, this representation is better for optimizations (instead<br>
of a magic constant 0xfffffe you have a transparent expression w+4).</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
To optimize 0xfffffe representation, the backend would need to decode<br>
the constant, which is the new code that has to be written for any<br>
relocation you'd like to use in reloc(). And if we allow such<br>
optimizations, we may end up with section bytes that are different<br>
from the reloc() constant anyway.<br></blockquote><div><br></div><div>Reloc constants are not meant to be "optimized", they are a means of communicating from the compiler to the linker.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note that either way the frontend/middleend knows the size of the<br>
relocated object (jump table entry).<br>
<div><div class="gmail-h5"><br>
><br>
>><br>
>> Do you suggest we use this to limit "reloc" to accepting only<br>
>> GlobalValue as the second argument instead of an arbitrary Constant?<br>
><br>
><br>
> No, we would accept your example and conceptually translate it into my<br>
> example.<br>
>><br>
>><br>
>> ><br>
>> >> On the other hand, it is possible for a constant expression in the IR<br>
>> >> to be lowered to something that is not a valid relocation target, and<br>
>> >> it is hard to detect this problem at the IR level.<br>
>> ><br>
>> ><br>
>> > Right, this is of course a problem we already have for aliasees and<br>
>> > constant<br>
>> > initializers.<br>
>> ><br>
>> >><br>
>> >> Also, separating the addend from the section data allows the backend<br>
>> >> to choose between .rel and .rela representations.<br>
>> ><br>
>> ><br>
>> > Do you have an example of a rela relocation which uses both r_addend and<br>
>> > the<br>
>> > underlying value in the object file?<br>
>><br>
>> The point of .rela is to allow addends that do not fit into the<br>
>> underlying value. Such addends can not be expressed as the third<br>
>> argument of reloc(), either. And IMHO the middleend should not worry<br>
>> about such details.<br>
><br>
><br>
> Something has to worry about them at some point. If a frontend/pass is<br>
> creating relocations, then it will need to know at least vaguely which<br>
> addend it wants. If that's the case, we can make it the single component<br>
> responsible for worrying about the whole addend, rather than the<br>
> responsibility being diffuse over a number of components.<br>
><br>
> Regarding width, I believe that no object format we support uses an addend<br>
> width wider than 64 bits, so we can just use a uint64_t.<br>
<br>
</div></div>You mean as a fourth argument to reloc()?<br></blockquote><div><br></div><div>No, I mean the third argument.</div><div><br></div><div>Peter</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> Peter<br>
>><br>
>><br>
>> ><br>
>> > Peter<br>
>> ><br>
>> >><br>
>> >> On Wed, Aug 26, 2015 at 3:29 PM, Peter Collingbourne via llvm-dev<br>
>> >> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> > On Wed, Aug 26, 2015 at 03:53:33PM -0400, Rafael Espíndola wrote:<br>
>> >> >> > I'm not sure if this would be sufficient. The R_ARM_JUMP24<br>
>> >> >> > relocation<br>
>> >> >> > on ARM has specific semantics to implement ARM/Thumb interworking;<br>
>> >> >> > see<br>
>> >> >> ><br>
>> >> >> ><br>
>> >> >> > <a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf" rel="noreferrer" target="_blank">http://infocenter.arm.com/<wbr>help/topic/com.arm.doc.<wbr>ihi0044e/IHI0044E_aaelf.pdf</a><br>
>> >> >> > Note that R_ARM_CALL has the same operation but different<br>
>> >> >> > semantics.<br>
>> >> >> > I suppose that we could try looking at the addend to decide which<br>
>> >> >> > relocation<br>
>> >> >> > to use, but this would mean adding more complexity to the<br>
>> >> >> > assembler<br>
>> >> >> > (along<br>
>> >> >> > with any pattern matching that would need to be done). It seems<br>
>> >> >> > simpler,<br>
>> >> >> > both conceptually and in the implementation, for the client to<br>
>> >> >> > directly say<br>
>> >> >> > what it wants in the object file.<br>
>> >> >> ><br>
>> >> >> > There's also the point that if @foo is defined outside the current<br>
>> >> >> > linkage<br>
>> >> >> > unit, or refers to a Thumb function, the above expression in a<br>
>> >> >> > constant<br>
>> >> >> > initializer would refer to the function's PLT entry or a shim, but<br>
>> >> >> > in<br>
>> >> >> > a<br>
>> >> >> > function it would refer to the function's actual address, so the<br>
>> >> >> > evaluation<br>
>> >> >> > of this expression would depend on whether it was constant folded.<br>
>> >> >> > (Although<br>
>> >> >> > on the other hand we might just declare that by using such a<br>
>> >> >> > constant<br>
>> >> >> > in a<br>
>> >> >> > global initializer that may be constant folded the client is<br>
>> >> >> > asserting that<br>
>> >> >> > it doesn't care which address is used.)<br>
>> >> >><br>
>> >> >> I am pretty sure there is use for some target specific expressions,<br>
>> >> >> my<br>
>> >> >> concerns are<br>
>> >> >> * Using a target specific expression when it could be represented in<br>
>> >> >> a<br>
>> >> >> target independent way (possibly a bit more verbose).<br>
>> >> ><br>
>> >> > Well I don't think there's a target independent way to write an<br>
>> >> > R_ARM_JUMP24<br>
>> >> > relocation, as there's no way to represent the PLT entry or<br>
>> >> > interworking<br>
>> >> > shim in IR.<br>
>> >> ><br>
>> >> >> * Using the raw relocation values, instead of something like<br>
>> >> >> thumb_addr_delta. With this the semantics of each constant<br>
>> >> >> expression<br>
>> >> >> are still documented in the language reference.<br>
>> >> ><br>
>> >> > I guess there are two ways we can go here:<br>
>> >> ><br>
>> >> > 1) expose the raw relocation values<br>
>> >> > 2) introduce new specific ConstantExpr subtypes for the<br>
>> >> > target-specific<br>
>> >> > things we need<br>
>> >> ><br>
>> >> > In this case I think we should do one or the other, I don't really<br>
>> >> > think<br>
>> >> > it's<br>
>> >> > worth adding a half measure of flexibility (e.g. providing a way to<br>
>> >> > specify<br>
>> >> > the addend of a R_ARM_JUMP24 when it will pretty much always be the<br>
>> >> > same).<br>
>> >> ><br>
>> >> > I like option 1 because it's more general purpose and ultimately less<br>
>> >> > of<br>
>> >> > an<br>
>> >> > impedance mismatch between what the client wants and what appears in<br>
>> >> > the<br>
>> >> > object file, and we can solve the documentation problem with<br>
>> >> > reference<br>
>> >> > to<br>
>> >> > the object file format documentation, but it would require our<br>
>> >> > documentation<br>
>> >> > to depend on sometimes poorly documented object file formats.<br>
>> >> ><br>
>> >> > Option 2 could look something like this (produces the same bytes as<br>
>> >> > "b<br>
>> >> > some_label" in every object format when targeting ARM, or "b.w<br>
>> >> > some_label"<br>
>> >> > when targeting Thumb):<br>
>> >> ><br>
>> >> > i32 arm_b (void ()* @some_label)<br>
>> >> ><br>
>> >> > and that would be easy to document on its own. The downside is that<br>
>> >> > it's<br>
>> >> > pretty specific to my use case, but maybe that's ok.<br>
>> >> ><br>
>> >> > 2 seems like it would be less implementation work, and doesn't<br>
>> >> > require<br>
>> >> > any<br>
>> >> > changes to the assembly format (and ultimately could be upgraded to 1<br>
>> >> > later<br>
>> >> > if needed), so maybe it's best to start with that.<br>
>> >> ><br>
>> >> >> >> Why do you need to be able to avoid them showing up in function<br>
>> >> >> >> bodies? It would be unusual but valid to pass the above value as<br>
>> >> >> >> an<br>
>> >> >> >> argument to a function.<br>
>> >> >> ><br>
>> >> >> > This was part of the proposal mainly for the constant folding<br>
>> >> >> > reasons<br>
>> >> >> > mentioned<br>
>> >> >> > above, but if we did go with a reloc expression we'd need to<br>
>> >> >> > encode<br>
>> >> >> > the<br>
>> >> >> > original constant address in the reloc for PC-relative<br>
>> >> >> > expressions,<br>
>> >> >> > which<br>
>> >> >> > wouldn't be necessary if we disallow it.<br>
>> >> >><br>
>> >> >> Seems better to make it explicit IMHO.<br>
>> >> ><br>
>> >> > Okay, but if we do introduce a new constant kind, there doesn't seem<br>
>> >> > to<br>
>> >> > be<br>
>> >> > much point in teaching the backend to lower it in a function, other<br>
>> >> > than<br>
>> >> > for completeness. If we can avoid having to do that, that seems<br>
>> >> > preferable.<br>
>> >> ><br>
>> >> >> BTW, about the assembly change: Please check what the binutils guys<br>
>> >> >> think of it. We do have extensions, but it is nice to at least let<br>
>> >> >> them know so that we don't end up with two independent solutions in<br>
>> >> >> the future.<br>
>> >> ><br>
>> >> > Yes if I ultimately go with 1.<br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> > --<br>
>> >> > Peter<br>
>> >> > ______________________________<wbr>_________________<br>
>> >> > LLVM Developers mailing list<br>
>> >> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> >> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > --<br>
>> > Peter<br>
><br>
><br>
><br>
><br>
> --<br>
> --<br>
> Peter<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>