search for: lto_module_get_symbol_name

Displaying 6 results from an estimated 6 matches for "lto_module_get_symbol_name".

2008 Feb 23
5
[LLVMdev] new LTO C interface
...was compiled under // extern const char* lto_module_get_target_triplet(lto_module_t mod); // // returns the number of symbols in the object module // extern uint32_t lto_module_get_num_symbols(lto_module_t mod); // // returns the name of the ith symbol in the object module // extern const char* lto_module_get_symbol_name(lto_module_t mod, uint32_t index); // // returns the attributes of the ith symbol in the object module // extern lto_symbol_attributes lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); // // instantiates a code generator // returns NULL if there is an error // extern lto_code_g...
2008 Feb 25
0
[LLVMdev] new LTO C interface
...rovide a corresponding dispose method, keeping the API self-contained. > extern const char* > lto_module_get_target_triplet(lto_module_t mod); LLVM nomenclature is triple, not triplet. > extern uint32_t > lto_module_get_num_symbols(lto_module_t mod); > > extern const char* > lto_module_get_symbol_name(lto_module_t mod, uint32_t index); > > extern lto_symbol_attributes > lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); Why uint32_t instead of size_t? > // > // frees all memory for a code generator > // upon return the lto_code_gen_t is no longer valid > /...
2016 Sep 30
7
libLTO C API stability policy
Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others
2014 Jan 22
2
[LLVMdev] [RFC] LTO: deallocating llvm::Module inside lto_codegen_add_module
...add_module) takes an LTOModule as an argument and links the latter's llvm::Module into its own. It does not change the latter's llvm::Module. The lto_module_dispose API call destroys an LTOModule. This frees the LTOModule's llvm::Module, but also invalidates strings returned by, e.g., lto_module_get_symbol_name. I propose that LTOCodeGenerator::addModule be changed to also deallocate the (consumed and redundant) llvm::Module and llvm::TargetMachine objects left behind in LTOModule. I.e., something akin to: diff --git a/include/llvm/LTO/LTOModule.h b/include/llvm/LTO/LTOModule.h index c70afa4..1...
2008 Feb 26
2
[LLVMdev] new LTO C interface
...const void*. Fixed. >> extern const char* >> lto_module_get_target_triplet(lto_module_t mod); > > LLVM nomenclature is triple, not triplet. Fixed. > >> extern uint32_t >> lto_module_get_num_symbols(lto_module_t mod); >> >> extern const char* >> lto_module_get_symbol_name(lto_module_t mod, uint32_t index); >> >> extern lto_symbol_attributes >> lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); > > Why uint32_t instead of size_t? I changed it to unsigned int. It is not pointer size dependent. > >> // >> // free...
2008 Feb 25
0
[LLVMdev] new LTO C interface
...plet(lto_module_t mod); > > > // > // returns the number of symbols in the object module > // > extern uint32_t > lto_module_get_num_symbols(lto_module_t mod); > > > // > // returns the name of the ith symbol in the object module > // > extern const char* > lto_module_get_symbol_name(lto_module_t mod, uint32_t index); > > > // > // returns the attributes of the ith symbol in the object module > // > extern lto_symbol_attributes > lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index); > > > // > // instantiates a code generator > /...