search for: bitcodesize

> It is simpler. There is not any Mach-O envelope. The platform linker > can directly read Mach-O files as well as llvm bit-code file (using > llvm bit-code file reader). > > > Not sure if/where the exact form of the Mach-O file that carries bit > > code is documented. Thanks for that. Yes, I see what you mean (no Mach-O envelope), yet there seems to be something

On Tue, Nov 4, 2014 at 9:10 PM, Bruce Hoult <bruce at hoult.org> wrote: > On Wed, Nov 5, 2014 at 2:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> > Does Apple support library/middleware providers shipping bitcode instead >> >>> > of object code? >>> >>> No. >>> >> >> Are there ever any plans to do so?

...s target info attached, so it's a matter of picking some convenient place to keep that info. Initially only Darwin would do this, but it would be a step up from the current explicit triple check. The wrapper has a standard header, same as the current header: - Magic - Version - BitcodeOffset - BitcodeSize The target can supply additional data to put after the header (and before the actual bitcode starts). Darwin would supply the CPUType field like it does now. This is 100% compatible with what exists today, but will be easy to extend for (ahem) other vendors who want wrappers. Any vendor who suppo...

> Aaah. Wasn't quite sure what you were doing here. I'm not positive > what llvm can emit via the writers (there's support for all parts of > the file format), but it could be extended to write one out. I'm just > not quite sure why :) > > -eric Well, ultimately I'm curious about what it would take to port a JVM based language (http://openquark.org) to