search for: mallocinst

Hi, I need to have special variants of some instructions, e.g. a special MallocInst that carries some additional information. Besides having this additional information, I want all of LLVM to recognize this instruction as a regular MallocInst. This special MallocInst need only exist inside LLVM; it need not be written out to bytecode. How to best implement this? This is w...

...ctions 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, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091016/793e9d36/attachment.html>

...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, > > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091016/c0d67813/attachment.html>

Just a note: I just checked in a change that corrects some very non-intuitive behavior of the AllocaInst & MallocInst classes. Before, the constructor would take a Type which would specify the return type of the instruction, instead of the operand type. Now it takes the operand type directly. More concretely: LLVM Code: X = alloca int ; int* Y = malloc int * ; int** Old C++ code: X = new AllocaIns...

...int main(int argc, char* argv[]) { void* buf = malloc(10 * sizeof(char*)); /* do sth with buf, so that it is not "optimized away" */ return 0; } When you compile this using a plain llvm-gcc, the call to libc-malloc is left inside.But compiling it with -O2 alters the call to llvm::MallocInst. Now i would like to know, why this is done. Is the libc-malloc still used? There is also a pass, called RaiseAllocation (well ... at least i think so) and i remember in previous versions (2.2) of llvm i read a commentary inside the sourcecode that the pass should be used with care because llvm::...

...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. Malloc and free will be represented normal 'call' instructions. > Is it possible to find out the size and beginning pointer of the > current stack frame, from a function operating outside of the > virtual mac...

...zes. >> >> I'm curious. Do we want to keep the free instruction? > > No, there's no reason to. There still are reasons to have it; just grep around for FreeInst. Function attributes are not yet sufficient to replace all of those yet. And if the ailgnment attribute on MallocInst were implemented, perhaps via posix_memalign or other target-specific mechanisms, then MallocInst would also have a reason to be kept. Dan

...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. Malloc and free will be > represented normal 'call' instructions. > > Is it possible to find out the size and beginning pointer of the current > stack frame, from a function operating outside of the virtual ma...

Hi, I recently looked quite some time for why poolalloc wouldn't transform calls to malloc() in my program, until I noticed that it handles calls to malloc() (eg, stdlib pass) -- but only transforms MallocInst's. Is there a general policy on how passes should behave? Should they handle both representations, is doing -raiseallocs the preferred way, or do we explicitely not want any single policy (ie, are there any hidden problems)? Perhaps this could also get a FAQ entry or sth. like that. Torvald

...nstruction itself > (except in cases like the store instr, which you've figured out > already). You can think of the variables that are printed out in the > .ll file as syntactic sugar to help with debugging. So, if you want > variables in a set, you can do something like: > > MallocInst *M = new MallocInst(...); > > std::set<Instruction*> LHSs; > > LHSs.insert(M); > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/lis...

...rg On Oct 27, 2007, at 11:10 AM, Torvald Riegel wrote: > Hi, > > I recently looked quite some time for why poolalloc wouldn't > transform calls > to malloc() in my program, until I noticed that it handles calls to > malloc() > (eg, stdlib pass) -- but only transforms MallocInst's. > > Is there a general policy on how passes should behave? Should they > handle both > representations, is doing -raiseallocs the preferred way, or do we > explicitely not want any single policy (ie, are there any hidden > problems)? > Perhaps this could also get a F...

...s. Do we want to keep the free instruction? >> >> No, there's no reason to. > > > There still are reasons to have it; just grep around for FreeInst. > Function > attributes are not yet sufficient to replace all of those yet. > > And if the ailgnment attribute on MallocInst were implemented, perhaps > via posix_memalign or other target-specific mechanisms, then > MallocInst > would also have a reason to be kept. isa<FreeInst>(X) can be replaced with: bool isFree(Instruction *X) { if (CallInst *CI = dyn_cast<CallInst>(X)) if (Function *...

Hey Everyone, I know that LLVM subscribes to the notion of "progress over backwards compatibility." And in that spirit, maybe someone could help me better understand the motivation behind removing the MallocInst? Is there a design doc anywhere? From a pragmatic sense, the IRBuilder's createMalloc, which was returning a MallocInst, was doing a lot of messy work for us users: http://llvm.org/docs/doxygen/html/Instructions_8cpp-source.html#l00463 . With MallocInst disappearing, is IRBuilder::c...

...mething along the lines of: std::vector<Value*> LHSs; for (std::vector<Value*>::iterator I = v.begin(), E = v.end(); I != E; ++I) { if (StoreInst *S = dyn_cast<StoreInst*>(*I)) { // Get the LHS for the store instruction LHSs.push_back(S->getOperand(1)); } else if (MallocInst *M = dyn_cast<MallocInst*>(*I)) { // M *is* the LHS of this instruction. LHSs.push_back(M); } else { assert(0 && "Some other instruction's in my list. This is bad!"); } } // Process the LHSs vector. Does this help? Or did I get it wrong? :-) -bw >...

...AM, Torvald Riegel wrote: > > Hi, > > > > I recently looked quite some time for why poolalloc wouldn't > > transform calls > > to malloc() in my program, until I noticed that it handles calls to > > malloc() > > (eg, stdlib pass) -- but only transforms MallocInst's. > > > > Is there a general policy on how passes should behave? Should they > > handle both > > representations, is doing -raiseallocs the preferred way, or do we > > explicitely not want any single policy (ie, are there any hidden > > problems)? > >...

Daniel Waterworth skrev: > 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

Hi Misha, Thanks for your answer I was doing this: ======================== BasicBlock *BBlock = new BasicBlock("entry", MyFunc); ... Value *Zero = ConstantSInt::get(Type::IntTy, 0); Value *UZero = ConstantUInt::get(Type::UIntTy, 0); MallocInst* mi = new MallocInst( STyStru ); mi->setName("tmp.0"); BBlock->getInstList().push_back( mi ); GetElementPtrInst *m_Next = new GetElementPtrInst(mi, UZero, Zero, "tmp.3", BBlock ); ... ======================== But I tried your code instead of the lines above: GetE...

...e this every time we wanted to analyze memory usage: > > if (CallInst *CI = dyn_cast<CallInst>(I)) > if (CI->getCalledFunction()->getName() == "malloc") { > // ... > } > whereas with the malloc instruction raising/lowering pass, you would say > if (MallocInst *MI = dyn_cast<MallocInst>(I)) { Not true at all. Consider the "llvm/IntrinsicInst.h" header, which lets us write stuff like this, today: if (MemCpyInst *MCI = dyn_cast<MemCpyInst>(I)) MCI->getSource() MCI->getLength() ... The one advantage that mallocinst ha...

...ruction is a pointer to the instruction itself (except in cases like the store instr, which you've figured out already). You can think of the variables that are printed out in the .ll file as syntactic sugar to help with debugging. So, if you want variables in a set, you can do something like: MallocInst *M = new MallocInst(...); std::set<Instruction*> LHSs; LHSs.insert(M); -bw

hello all, If i have an IR instruction of the form %tmp10 = call sbyte* %malloc( uint 4 ) ; <sbyte*> [#uses=1] %tmp10 = cast sbyte* %tmp10 to int* ; <int*> [#uses=1] store int* %tmp10, int** %t which is nothin but a malloc call how can i get %tmp into maybe a variable set. If i have a store instruction then it is pretty much simpler as the getOperand(1) can give