search for: naasking

...alloc with a large value will cause a real program to fail. This translation would seem to make potentially failing programs succeed. Seems counter-intuitive to me, but as I said, perhaps I just need to read up on this "as-if" rule. Sandro On Fri, May 2, 2008 at 1:55 PM, Sandro Magi <naasking at gmail.com> wrote: > > On Thu, May 1, 2008 at 6:54 PM, Chris Lattner <sabre at nondot.org> wrote: > > > > > I don't see how this could be true in general, without either > > > knowledge of the malloc implementation, which would be fine, or > &gt...

To this end, are there any implicit allocations being done by generated LLVM code, other than the system stack? Sandro On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: > Given my recent posts, I think it's obvious that I'm trying to figure > out how to build a resource-aware VM for a high-level language. > > I've figured out adequate solutions for most of the problems I've > encountered, including separate he...

Given my recent posts, I think it's obvious that I'm trying to figure out how to build a resource-aware VM for a high-level language. I've figured out adequate solutions for most of the problems I've encountered, including separate heaps, quotas, etc. However, I'm not sure how I can account for a thread's stack space. Given a language process (LP) running in a heap with a

On Wed, Mar 26, 2008 at 2:01 PM, Jonathan S. Shapiro <shap at eros-os.com> wrote: > > All functions in the tutorial are referenced by their Function*. The > > Function* uniquely identifies a function and is independent of the name. > > I had understood that. > > So now I have compiled and run my top level expression's anonymous > function. How do I go

On Fri, May 2, 2008 at 2:07 PM, Sandro Magi <naasking at gmail.com> wrote: > Sorry, clicked send by accident. It seems there's some background I'm > missing though. Can I read up on this "as-if" rule anywhere? > >From the latest C++0x draft (n2588), 1.9/1 [intro.execution]: "The semantic descriptions in this Int...

On Wed, 2008-03-26 at 10:40 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > The Kaleidoscope tutorial has us "interpreting" top-level expressions by > > generating a one-shot anonymous procedure and executing that. Once the > > expressions have been executed, these procedures will never be called > > again. > > > >

...location primitives as function pointers. So a program or language with real-time constraints where an incremental GC is preferable, and where an efficient, non-incremental GC is used for other tasks, can be expressed as partitioned heaps each with their own GC. Sandro On 6/2/07, Sandro Magi <naasking at gmail.com> wrote: > Many VMs focus on performance, optimizations, memory consumption, etc. > but very few, if any, focus on fault isolation and security. Given > memory safety, any VM reduces to capability security, which is > sufficient to implement most security policies of inte...

...ate calls to runtime libraries (e.g. libstdc++ and libgcc), we don't have control over when they do allocations. The libstdc++ calls show up in the .ll file, but the libgcc ones don't. I don't think any libgcc routines do heap allocations. -Chris > On 6/18/07, Sandro Magi <naasking at gmail.com> wrote: >> Given my recent posts, I think it's obvious that I'm trying to figure >> out how to build a resource-aware VM for a high-level language. >> >> I've figured out adequate solutions for most of the problems I've >> encountered, i...

On Thu, May 1, 2008 at 6:54 PM, Chris Lattner <sabre at nondot.org> wrote: > > > I don't see how this could be true in general, without either > > knowledge of the malloc implementation, which would be fine, or > > presuming knowledge of the target, which would not be fine. If > > "malloc(sizeof(int))" were changed to

On Thu, 1 May 2008, Sandro Magi wrote: >> If LLVM is able to eliminate all users of the malloc assuming the >> malloc succeeded (as in this case), then it is safe to assume the malloc >> returned success. > > I don't see how this could be true in general, without either > knowledge of the malloc implementation, which would be fine, or > presuming knowledge of

On 6/6/07, Sandro Magi <naasking at gmail.com> wrote: > On 6/5/07, John Criswell <criswell at cs.uiuc.edu> wrote: > > > > To be honest, while I understand your questions, I do not understand the > > context in which you are asking them. Are you asking if LLVM provides > > any facilities to provi...

Many VMs focus on performance, optimizations, memory consumption, etc. but very few, if any, focus on fault isolation and security. Given memory safety, any VM reduces to capability security, which is sufficient to implement most security policies of interest; however, most such VMs still ignore two main attack vectors from malicious code: DoS attack on memory allocation, and DoS against the CPU.

...g GC may require using the LLVM GC intrinsics as described in this document (http://llvm.org/docs/GarbageCollection.html), but just segmenting the heap into multiple heaps should not require any new instructions or intrinsics to be added. -- John T. > Sandro > > On 6/2/07, Sandro Magi <naasking at gmail.com> wrote: > >> Many VMs focus on performance, optimizations, memory consumption, etc. >> but very few, if any, focus on fault isolation and security. Given >> memory safety, any VM reduces to capability security, which is >> sufficient to implement most s...

On 6/5/07, John Criswell <criswell at cs.uiuc.edu> wrote: > > To be honest, while I understand your questions, I do not understand the > context in which you are asking them. Are you asking if LLVM provides > any facilities to provide these protections, or are you asking if we've > added any special features to LLVM (or to SVA; our research work based > on LLVM) to

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The current semispace collector includes

On 6/18/07, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 18 Jun 2007, Sandro Magi wrote: > > Ok, so if I needed very precise control over the allocation of memory, > > then I should avoid using integers with bit widths larger than 64 bits > > (or perhaps 128)? Is there a hard rule for an integer being stack > > allocated, ie. one that doesn't depend on

The ref manual states: The optional "tail" marker indicates whether the callee function accesses any allocas or varargs in the caller. If the "tail" marker is present, the function call is eligible for tail call optimization. Note that calls may be marked "tail" even if they do not occur before a ret instruction. Does "eligible" in the above mean that some

On 6/20/07, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > > Depending on your application, you could read debug info, > > > > Actually I am not using llvm-gcc. I'm just targeting a new language and > it would have been a lot easier implementing the compiler with LLVM if > it had this kind of feature (string <-> type). But if it's not feasible,

How about if I were to use LLVM's JIT? I suspect plenty of allocations are performed in the JIT. Sandro On 6/20/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 20 Jun 2007, Sandro Magi wrote: > > To this end, are there any implicit allocations being done by > > generated LLVM code, other than the system stack? > > heap allocations? Only malloc/free. Note

On 7/10/07, Chris Lattner <sabre at nondot.org> wrote: > On Sun, 8 Jul 2007, Sandro Magi wrote: > > How about if I were to use LLVM's JIT? I suspect plenty of allocations > > are performed in the JIT. > > The JIT does a ton of heap allocation. There is no way to approximate it > from the code you give it. I don't need to approximate it, but I'd like to