On Tue, 10 Jul 2007, Sandro Magi wrote:>> used. Your choices are to either override malloc/free for both the JIT >> and the program or for neither of them. > > I want to 'intercept' ALL allocations actually, including the stack if > possible, so the above suits me just fine.Ok, just provide your own malloc/free. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Jul 10, 2007, at 15:39, Chris Lattner wrote:> On Tue, 10 Jul 2007, Sandro Magi wrote: > >>> used. Your choices are to either override malloc/free for both >>> the JIT and the program or for neither of them. >> >> I want to 'intercept' ALL allocations actually, including the >> stack if possible, so the above suits me just fine. > > Ok, just provide your own malloc/free. :)One of the existing malloc replacements should provide hints for how to go about that. www.hoard.org for one. The details on Windows are especially complicated. Be aware that even doing this won't reliably intercept all allocations. With Mac OS X, Mach's vm_allocate call is accessible. With Unix, mmap with flags = MAP_ANON allocates memory. And even still, the implementations of these aren't magic; it's possible to make the syscalls without linking to these symbols per se. There are likely further facilities to distrust on any given platform, as well. If you're intending to sandbox untrusted third-party code, then you need to consider these issues. Good luck, Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070710/ba47a0ae/attachment.html>
On 7/10/07, Gordon Henriksen <gordonhenriksen at mac.com> wrote:> > One of the existing malloc replacements should provide hints for how to go > about that. www.hoard.org for one. The details on Windows are especially > complicated. > > Be aware that even doing this won't reliably intercept all allocations. With > Mac OS X, Mach's vm_allocate call is accessible. With Unix, mmap with flags > = MAP_ANON allocates memory. And even still, the implementations of these > aren't magic; it's possible to make the syscalls without linking to these > symbols per se. There are likely further facilities to distrust on any given > platform, as well. If you're intending to sandbox untrusted third-party > code, then you need to consider these issues.Ouch. Sandboxing untrusted code would certainly be an interesting application, but I'm not that ambitious. My intended usage is a custom VM with a custom bytecode JIT'd using LLVM. I was going to track activation frames by CPS-transforming my input program, so the LLVM stack should run in constant space. Please let me know if there's some type of allocation LLVM might perform that doesn't fall under these two categories. Sandro