similar to: [LLVMdev] Memory Altering/Accessing Instructions

Prakash Prabhu wrote: > Hi all, > > Would it be correct to say that the only instructions in LLVM IR that > modify/access memory potentially are the following: > I believe that every instruction has a mayWriteToMemory()/mayReadToMemory() method that you can use to determine this information. See http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen info on

On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >>> There is no good reason for malloc to be an instruction anymore. >>> I'd >>> be very happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No,

Hello, I'm writing a virtual machine that functions as a sandbox based on llvm. In order to prevent programs from accessing memory that has not been allocated to them, I want to replace calls to malloc and free with calls to a logged functions that will record the memory that is being allocated to the program. Is it possible to cast/convert a MallocInst or FreeInst to a CallInst? Thanks,

On Oct 16, 2009, at 4:43 AM, Daniel Waterworth wrote: > Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and > DisableSymbolSearching to cause malloc and free calls to be handled > by my logging functions. Sorry for the unnecessary list mail. No problem, this is a better way to go. The MallocInst and FreeInst instructions are about to be removed from LLVM IR.

On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > > On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: > >>>> There is no good reason for malloc to be an instruction anymore. >>>> I'd >>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>>

Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and DisableSymbolSearching to cause malloc and free calls to be handled by my logging functions. Sorry for the unnecessary list mail. Is it possible to find out the size and beginning pointer of the current stack frame, from a function operating outside of the virtual machine, but called by a function within it? Thanks, Daniel

Hi everyone, I noticed that MallocInst and FreeInst have been removed from the LLVM IR as well as the language reference[1]. May I propose that at least some placeholder is left in that document telling the reader that these instructions have been removed. This should be kept in at least until there is one official release that does not support these instructions anymore. The same goes for

Thanks very much. I only have one more question, (hopefully), which is, is there a better way of finding the direction of stack growth other than: static bool StackCmp(void *ptr) { volatile int a; return (void *)&a > ptr; } bool FindStackDirection() { volatile int a; return StackCmp((void *)&a); } Preferably one which isn't destroyed by optimization. Thanks again,

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);

Hi Dan, Thanks for the reply. I got the labels for each outgoing edge (at the source node's 'structure' field) working. Is there a way to find out the outgoing edge number from EdgeIter. (Basically the Node in my graph has a a bunch of outgoing edges, so that I can just index into that collection within the node to get the appropriate edges' attributes). regards, Prakash On Tue,

Hi Eli, Thanks for the reply. I tried with -Xlinker="-ldl ". However it does not seem to make a difference. It seems that when bugpoint is run with --run-jit, the linker args are not passed to gcc (from tools/bugpoint/ExecutionDriver.cpp) : if (InterpreterSel == RunLLC || InterpreterSel == RunCBE || InterpreterSel == CBE_bug || InterpreterSel == LLC_Safe) RetVal =

Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of doing heap allocation going forward? :-) Garrison On Dec 7, 2009, at 11:18, Chris Lattner wrote: > > On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > >> Hi everyone, >> >> I noticed that MallocInst and FreeInst have been removed from the

Hi Prakash, I don't know of an easy way to do this, other than to use random-access iterators so you can compute the distance between the edge and the beginning of the list of edges. Dan On Sep 16, 2008, at 2:58 PM, Prakash Prabhu wrote: > Hi Dan, > > Thanks for the reply. I got the labels for each outgoing edge (at the > source node's 'structure' field) working. Is

Hi, Is there a way, from within an opt pass, to find the correspondence between an LLVM IR object and C source code (basically line number info similar to the one used with gcc + gdb to help debugging ), assuming either a llvm-gcc front end ? Sorry if this question was asked before. Thanks for your time. - Prakash

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

Hi all, I too am getting this error for x86_64 when I am trying to use the Data Structure Analysis ...I svn upped both the llvm main branch and the poolalloc today in the morning and recompiled everything from scratch : $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so -ds-aa < o.bc opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual void

Hi, I have a program that runs when statically compiled using llc and gcc but crashes with a segmentation fault when run with lli. I am trying to debug it with bugpoint and the initial part of bugpoint seems to be suggesting that I am somehow missing the linking with the libraries having dlsym/dlopen although I am passing it to lli : *$ bugpoint -run-jit

Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one

Hi Prakash, Unfortunately it looks like you need to do quite a bit of investigation into this. However, I hope I can provide some useful tips. 1. In general, lli and llc generate exact the same code except lli default to static codegen while llc defaults to dynamic-no-pic codegen. So try passing -relocation-model=dynamic-no-pic to lli. If this works, that means there are issues with

So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics? Garrison On Dec 7, 2009, at 12:21, Chris Lattner wrote: > > On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > >> Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of