similar to: [LLVMdev] new LTO C interface

Hi Nick, I don't have any comments on the substance of the APIs (I'm not expert in this area), just some style notes. Overall, the capitalization style is inconsistent with the bulk of the C bindings, which are more Carbon than GNU. On Feb 23, 2008, at 01:34, Nick Kledzik wrote: > #include <stdint.h> > #include <stdbool.h> Note that MSVC++ still doesn't

More stylistic nitpicking for consistency sakes... 1. __LTO__ -> LLVM_C_LTO 2. Do we need those #include's? 3. Rather than using underscore in function names, e.g. lt_foo_bar, use capital letters and also start with prefix LLVM. e.g. LLVMLTOFooBar. 4. lto_codegen_release -> lto_codegen_release_memory to be clearer and more consistent. 5. Use C comments /* ... */? 6. Please start

I've updated the header (enclosed).  On Feb 24, 2008, at 11:24 PM, Evan Cheng wrote: > 1. __LTO__ -> LLVM_C_LTO > 3. Rather than using underscore in function names, e.g. lt_foo_bar, > use capital letters and also start with prefix LLVM. e.g. > LLVMLTOFooBar. As we discussed, this is interface is llvm independent. It may even migrate out of include/llvm-c at some

On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: > > 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

On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 14 November 2013 18:01, Stephen Checkoway <s at pahtak.org> wrote: >> >> 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

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

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

Taking a really quick at the gold code it looks like it tries to keep 8176 files open. I would suggest putting a breakpoint in Descriptors::close_some_descriptor and checking why it is failing to close the files. On 15 November 2013 11:03, Stephen Checkoway <s at pahtak.org> wrote: > > On Nov 15, 2013, at 10:19 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >