search for: cferror

...ude <stddef.h> > > extern const char* > lto_get_error_message(); I've tried not to create thread-unsafe designs in the rest of the bindings. I return a malloced error message by optional output parameters and provide a generic dispose function (LLVMDisposeMessage). Copying CFError's design might be smarter still. > extern bool > lto_module_is_object_file_in_memory(const uint8_t* mem, size_t > length); > > extern bool > lto_module_is_object_file_in_memory_for_target(const uint8_t* mem, > size_t length, >...

...t; extern const char* >> lto_get_error_message(); > > I've tried not to create thread-unsafe designs in the rest of the > bindings. I return a malloced error message by optional output > parameters and provide a generic dispose function > (LLVMDisposeMessage). Copying CFError's design might be smarter still. There are other things not thread safe about the API. Adding a string return would complicate the API. And it is possible to make the API thread safe in the future by making lto_get_error_message() return a per-thread string. > >> extern bool...

Hello. I work at Apple on our linker. We are working to improve support for llvm in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h> a C++ interface which allows the linker to process llvm bitcode files along with native mach-o object files. For the next step we'd like our other tools like nm, ar, and lipo to be able to transparently process bitcode files