search for: functionlist

...ook for those that are Function declarations (use the > "Function::isDeclaration()" method), and then placing them in the > appropriate place in your assembly file. > > Would that work? Hi Bill, Function definitions and declarations that are parsed by clang make part of the FunctionList in Module. However the libcalls that are created during the lowering do not make part of this list. For example PIC16 does not support shift operation of 16 bits. For this LLVM generates the libcall. For creating such a call it uses ExternalSymbol and therefore it is not available in the FunctionL...

...unctionPassManager = new llvm::FunctionPassManager( module.get() ); targetMachine->addPassesToEmitFile( *functionPassManager, llvm::fouts(), llvm::TargetMachine::CGFT_AssemblyFile, optLevel ); functionPassManager->doInitialization(); llvm::Module::FunctionListType &functionList = module->getFunctionList(); for ( llvm::Module::FunctionListType::iterator it=functionList.begin(); it!=functionList.end(); ++it ) functionPassManager->run( *it ); delete functionPassManager; It seems very bizarre to me that the back end can g...

Hi Sachin, The declaration of functions called via the "call" instruction is a GlobalValue in your Module. You can go through all of the GlobalValues, look for those that are Function declarations (use the "Function::isDeclaration()" method), and then placing them in the appropriate place in your assembly file. Would that work? -bw On Jan 28, 2009, at 12:23 AM,

Hi, Probably I did not mention my question correctly. I need to emit declarations of the libcalls (that are made in the current module) at the beginning of the assembly file. The class "Module" does not maintain any list of the libcalls made during the program. Although, it maintains lists of all the global variables and functions in the current module. Traversing each

...ppearance doesn't seem to be bad thing. Are there any technical issues with addition of ordering? I guess class Module and it's uses in parser (and linker) will be mostly affected. Currently Module stores different entities separately and concatenates all top level asm into single string. FunctionListType FunctionList; ///< The Functions in the module std::string GlobalScopeAsm; ///< Inline Asm at global scope. Are there any other issues? Regards, Sergey Y.

> Are there any reasons why option can't be supported by llvm? It is hard and has very few users. For this to work you would have to add ordering information to the LLVM IL. It looks easier to patch eglibc. > Regards, > Sergey Yakoushkin Cheers, -- Rafael Ávila de Espíndola

...be bad thing. > Are there any technical issues with addition of ordering? > I guess class Module and it's uses in parser (and linker) will be > mostly affected. > Currently Module stores different entities separately and concatenates > all top level asm into single string. >  FunctionListType FunctionList; ///< The Functions in the module >  std::string GlobalScopeAsm;    ///< Inline Asm at global scope. > > Are there any other issues? Take a look at gcc's implementation. They need to keep the order of every definition they see. It also has other issues: 1654 /...

Ms Brukman, Thanks for your reply.Just clarifying my question.I actually wanted to randomize the static layout of function code in the executable file.Sorry for writing in confusing manner. T Misha Brukman <brukman at cs.uiuc.edu> wrote: On Thu, Jun 02, 2005 at 02:12:22PM -0700, Tanu Sharma wrote: > By randomization of functions I mean the manner in whch they are > called , so

Hi, llvm doesn't support -fno-toplevel-reorder option which affects glibc/eglibc for some targets. http://www.llvm.org/bugs/show_bug.cgi?id=6364 >From conversations with gcc and eglibc maintainers, seems option is highly expected and is not going to deprecate. >> 2010/2/23 Ian Lance Taylor <iant at google.com>: >> If option is going to deprecate in gcc in near future as