search for: lto_get_error_messag

...nce to a code generator typedef struct LTOCodeGenerator* lto_code_gen_t; #ifdef __cplusplus extern "C" { #endif // // returns a printable string // extern const char* lto_get_version(); // // returns the last error string or NULL if last operation was sucessful // extern const char* lto_get_error_message(); // // validates if a file is a loadable object file // extern bool lto_module_is_object_file(const char* path); // // validates if a file is a loadable object file compilable for requested target // extern bool lto_module_is_object_file_for_target(const char* path,...

...def __cplusplus > extern "C" { > #endif > > // > // returns a printable string > // > extern const char* > lto_get_version(); > > > // > // returns the last error string or NULL if last operation was > sucessful > // > extern const char* > lto_get_error_message(); > > > // > // validates if a file is a loadable object file > // > extern bool > lto_module_is_object_file(const char* path); > > > // > // validates if a file is a loadable object file compilable for > requested target > // > extern bool > lto_mod...

...ik wrote: > #include <stdint.h> > #include <stdbool.h> Note that MSVC++ still doesn't support C99, and is a target for LLVM. I'd suggest bool -> int and uint8_t* -> void* to resolve the dependency. > #include <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_mod...

...of lto is all in C++, so it will build with MSVC++. The only thing that might get tripped up by the use of bool in the interface is if someone tries to write a C (not C++) client (meaning a linker) using MSVC. >> #include <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. There...

...has 2 objects in memory at once but keeps all the file descriptors open? That is odd. I will debug it in a sec, but we have in the claim_file_hook: if (code_gen) { if (lto_codegen_add_module(code_gen, M)) { (*message)(LDPL_ERROR, "Error linking module: %s", lto_get_error_message()); return LDPS_ERR; } } lto_module_dispose(M); In fact, with current gold we call get_view, so the plugin uses the same fd as gold. It might actually be a bug with gold trying to cache too many open files. How are you trying to build it? Cheers, Rafael

On Nov 14, 2013, at 8:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > But gold has at most 2 objects loaded at any time. Are you sure about that? I haven't looked into it but while building Chromium with LTO, I get: ../../third_party/gold/gold64: fatal error: out of file descriptors and couldn't close any clang: error: linker command failed with exit code 1

...e but keeps all the file descriptors open? > > That is odd. I will debug it in a sec, but we have in the claim_file_hook: > > if (code_gen) { > if (lto_codegen_add_module(code_gen, M)) { > (*message)(LDPL_ERROR, "Error linking module: %s", > lto_get_error_message()); > return LDPS_ERR; > } > } > > lto_module_dispose(M); > > In fact, with current gold we call get_view, so the plugin uses the > same fd as gold. It might actually be a bug with gold trying to cache > too many open files. > > How are you trying to b...

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

...escriptors open? >> >> That is odd. I will debug it in a sec, but we have in the claim_file_hook: >> >> if (code_gen) { >> if (lto_codegen_add_module(code_gen, M)) { >> (*message)(LDPL_ERROR, "Error linking module: %s", >> lto_get_error_message()); >> return LDPS_ERR; >> } >> } >> >> lto_module_dispose(M); >> >> In fact, with current gold we call get_view, so the plugin uses the >> same fd as gold. It might actually be a bug with gold trying to cache >> too many open files....