search for: lto_module_get_symbol_nam

...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_...

...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 >...

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

...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.....

...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. > >> // >> // fre...

...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 >...