<div dir="ltr">Thank you for providing the explanation for how ADRP works...something I should have done myself.<div><br></div><div>With this explanation in hand, one other alternative I was looking at was using a linkerscript to essentially rebase the code and have ADRP instructions that would address the correct location as a result. However, I am not a linkerscript expert, so I am not sure if such a thing is even possible or would make much sense. However, it may provide a legitimate shortcut to a solution which doesn't involve adding a feature to the toolchain.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 21, 2018 at 9:04 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21 May 2018 at 13:57, Bruce Hoult via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> "ADRL produces position-independent code, because the address is calculated<br>
> relative to PC."<br>
><br>
> From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a 20<br>
> bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by 4096)<br>
> or AUIPC in MIPS (16 bits multiplied by 65636 there).<br>
<br>
</span>Afraid not. It really is (PC & ~0xfff) + n * 0x1000. So it does<br>
require 12-bit alignment of any code section.<br>
<br>
Now that you mention the MIPS & RISC-V alternatives, I'm not sure why<br>
ARM actually made that choice. It obviously saves you a handful of<br>
transistors but I can't quite believe that's all there is to it.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>