search for: fntype

...arameterType(param->type())); } const ParameterList & params = type->params(); for (ParameterList::const_iterator it = params.begin(); it != params.end(); ++it) { const ParameterDefn * param = *it; args.push_back(genDIParameterType(param->type())); } DICompositeType fnType = dbgFactory_.CreateCompositeType( dwarf::DW_TAG_subroutine_type, dbgCompileUnit_, "", dbgFile_, 0, // Source line 0, // Size 0, // Align 0, // Offset 0, // Flags DIType(), dbgFactory_.GetOrCreateArray(args.data(), args.siz...

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

...(trunk version) Basically I recreate a function over and over again, and pretty sure that my code doesn't cause the leak while(true) { Function *fn = module->getFunction(name); if (fn) fn->eraseFromParent(); fn = cast<Function>(module->getOrInsertFunction(name, fnType)); fillFunction(fn); //Fill function with some blocks and instructions.. } Is there any documentation guideline on how to manage memory with LLVM? . I am kind of lost here. I tried anything I could but it seems the leaks won't go away Valgrind gives me lots of .. 110,560 bytes in 1,382 b...

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

...) > { >  Function *fn = module->getFunction(name); >    if (fn) >       fn->eraseFromParent(); Err, shouldn't you delete fn here? I'm pretty sure that this just removes the function from the module. >    fn =  cast<Function>(module->getOrInsertFunction(name, fnType)); >    fillFunction(fn); //Fill function with some blocks and instructions.. > } Reid

...just > removes the function from the module. Doxygen says that: "eraseFromParent - This method unlinks 'this' from the containing module and deletes it." so it should be fine just calling erase. > >>    fn =  cast<Function>(module->getOrInsertFunction(name, fnType)); >>    fillFunction(fn); //Fill function with some blocks and instructions.. >> } > > Reid > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailma...

...rameterList::const_iterator it = params.begin(); it != > params.end(); ++it) { >     const ParameterDefn * param = *it; >     args.push_back(genDIParameterType(param->type())); >   } Don't do that. I know it looks right, but it's broken in DIFactory. >   DICompositeType fnType = dbgFactory_.CreateCompositeType( >       dwarf::DW_TAG_subroutine_type, >       dbgCompileUnit_, I use the file here, not the compile unit... But again, I could be wrong. Hope that puts you in the right direction. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights,...

...gin(); it != > > params.end(); ++it) { > > const ParameterDefn * param = *it; > > args.push_back(genDIParameterType(param->type())); > > } > > Don't do that. I know it looks right, but it's broken in DIFactory. > > > > DICompositeType fnType = dbgFactory_.CreateCompositeType( > > dwarf::DW_TAG_subroutine_type, > > dbgCompileUnit_, > > I use the file here, not the compile unit... But again, I could be wrong. > > Hope that puts you in the right direction. > OK I made 3 changes: -- changed isDefinit...

Hi LLVM devs, I work on a pass that creates multiple versions of a code region and switches between them. The decision about the version to be selected is taken by an external runtime system. I insert callbacks to this system in my code to pass the control of the execution. All callbacks are written in inline assembly, in macros. The problem comes when I need to send some information from

...(); it != > > params.end(); ++it) { > > const ParameterDefn * param = *it; > > args.push_back(genDIParameterType(param->type())); > > } > > Don't do that. I know it looks right, but it's broken in DIFactory. > > > > DICompositeType fnType = dbgFactory_.CreateCompositeType( > > dwarf::DW_TAG_subroutine_type, > > dbgCompileUnit_, > > I use the file here, not the compile unit... But again, I could be wrong. > > Hope that puts you in the right direction. > > OK I made 3 changes: > -- chang...

...I think that I will have a problem latter. So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine the same scenario with f that calls g while...

...I think that I will have a problem latter. So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) class FnDescriptor { StringRef name; FunctionType fnType; LinkageType linkage; }; class FnState { llvm::Module* definedModule; /* maybe a llvm::ObjectImage* ? */ List<RelocationTable*>* users, void* currentPointer }; map<FnDescriptor, FnState> it could be really useful. Let's imagine the same scenario with f that calls g while...

...problem latter. > > So, for the moment, I'm a little bit stuck with MCJIT. Something that could be really useful could be a mcjit that acts as a linker. If MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescriptor, FnState> > > it could be really useful....

...er. > > So, for the moment, I'm a little bit stuck with MCJIT. Something that > could be really useful could be a mcjit that acts as a linker. If > MCJIT could have a map like this (I give a pseudo-c++ code) > > class FnDescriptor { > StringRef name; > FunctionType fnType; > LinkageType linkage; > }; > > class FnState { > llvm::Module* definedModule; > /* maybe a llvm::ObjectImage* ? */ > List<RelocationTable*>* users, > void* currentPointer > }; > > map<FnDescriptor, FnState> > > it could be really useful....

...the moment, I'm a little bit stuck with MCJIT. Something that >> could be really useful could be a mcjit that acts as a linker. If >> MCJIT could have a map like this (I give a pseudo-c++ code) >> >> class FnDescriptor { >> StringRef name; >> FunctionType fnType; >> LinkageType linkage; >> }; >> >> class FnState { >> llvm::Module* definedModule; >> /* maybe a llvm::ObjectImage* ? */ >> List<RelocationTable*>* users, >> void* currentPointer >> }; >> >> map<FnDescriptor, FnSt...

...ttle bit stuck with MCJIT. Something that >>> could be really useful could be a mcjit that acts as a linker. If >>> MCJIT could have a map like this (I give a pseudo-c++ code) >>> >>> class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>* users, >>> void* currentPointer >>> }; >&gt...

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

...le bit stuck with MCJIT. Something >>> that could be really useful could be a mcjit that acts as a linker. >>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>> >>> class FnDescriptor { >>> StringRef name; >>> FunctionType fnType; >>> LinkageType linkage; >>> }; >>> >>> class FnState { >>> llvm::Module* definedModule; >>> /* maybe a llvm::ObjectImage* ? */ >>> List<RelocationTable*>* users, >>> void* currentPointer >>> }; >&gt...

...T. Something >>>> that could be really useful could be a mcjit that acts as a linker. >>>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>>> >>>> class FnDescriptor { >>>> StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>>> List<RelocationTable*>* users, >>>> void* curren...

.... Something >>>> that could be really useful could be a mcjit that acts as a linker. >>>> If MCJIT could have a map like this (I give a pseudo-c++ code) >>>> >>>> class FnDescriptor { >>>> StringRef name; >>>> FunctionType fnType; >>>> LinkageType linkage; >>>> }; >>>> >>>> class FnState { >>>> llvm::Module* definedModule; >>>> /* maybe a llvm::ObjectImage* ? */ >>>> List<RelocationTable*>* users, >>>> void* curren...