[LLVMdev] Position-independent stacks
vadimcn at gmail.com
Thu Jan 23 15:23:04 PST 2014
Thanks Mark! That'd be a useful starting point.
For the rest of the people here: to be a bit more specific, I am having
doubts about the following:
- 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?
- Can frame pointers be disabled on all architectures? If not, is the
frame pointer chain always walkable?
- 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).
On Thu, Jan 23, 2014 at 8:22 AM, Mark Seaborn <mseaborn at chromium.org> wrote:
> On 22 January 2014 22:10, Vadim <vadimcn at gmail.com> wrote:
>> 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 greenlets <http://stackoverflow.com/a/17447308>),
>> because you'd be able to easily save threadlet state from one OS thread and
>> later restore it into another.
>> 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
>> 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",
>> 2. either turn off frame base pointers, or make sure they are adjusted
>> after the stack had been relocated,
>> 3. ... can't think of anything else, actually.
>> What do you guys think? Any reasons this approach wouldn't fly?
> I've implemented something similar, but with the motivation of
> implementing SFI sandboxing rather than making the stack relocatable.
> The code is here: https://codereview.chromium.org/29743003/ In
> particular, see the ExpandAlloca pass.
> 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:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev