<div dir="ltr"><div><div><div>Thanks Mark!  That'd be a useful starting point.<br></div><div><br><br></div><div>For the rest of the people here: to be a bit more specific, I am having doubts about the following:<br></div>
<div>
</div>- Can later optimization passes or code generation still create machine code that takes and stores (in a register perhaps) an address of something on the stack, even if not semantically visible to the programmer?   Can this somehow be detected?<br>

</div>- Can frame pointers be disabled on all architectures?  If not, is the frame pointer chain always walkable?<br>- Can frame pointers be disabled on a per-function basis?  (this is in case not the whole program's stacks need to be made relocatable).<br>
<br></div>Vadim<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 8:22 AM, Mark Seaborn <span dir="ltr"><<a href="mailto:mseaborn@chromium.org" target="_blank">mseaborn@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 January 2014 22:10, Vadim <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div>Hi,</div><div>I am toying with an idea of having LLVM generate code that has position-independent stacks.   This would be a very useful property for implementing all sorts of micro-thread libraries (I am thinking something similar to Python <a href="http://stackoverflow.com/a/17447308" target="_blank">greenlets</a>), because you'd be able to easily save threadlet state from one OS thread and later restore it into another.</div>


<div><br></div><div>On the surface, it seems entirely do-able - basically, one needs to get rid of all the things that point into the stack.  It should be sufficient to:</div><div>1. write a function pass that finds all local variables, whose address is ever taken, and hoists them into a heap-allocated secondary "stack frame", </div>


<div>2. either turn off frame base pointers, or make sure they are adjusted after the stack had been relocated,</div><div>3. ... can't think of anything else, actually.</div><div><br></div><div>What do you guys think?  Any reasons this approach wouldn't fly?</div>

</div></blockquote><div><br></div><div>I've implemented something similar, but with the motivation of implementing SFI sandboxing rather than making the stack relocatable.</div><div><br></div><div>The code is here: <a href="https://codereview.chromium.org/29743003/" target="_blank">https://codereview.chromium.org/29743003/</a>  In particular, see the ExpandAlloca pass.</div>

<div><br></div><div>That code implements sandboxing at the level of LLVM IR.  It restricts all memory accesses to a range of address space by truncating the memory address and adding a base pointer.  Here are some notes explaining further:  <a href="https://docs.google.com/presentation/d/1RD3bxsBfTZOIfrlq7HzGMsygPHgb61A1eTdelIYOurs/edit" target="_blank">https://docs.google.com/presentation/d/1RD3bxsBfTZOIfrlq7HzGMsygPHgb61A1eTdelIYOurs/edit</a></div>

<div><br></div><div>Cheers,</div><div>Mark</div><div><br></div></div></div></div>
</blockquote></div><br></div>