<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Luke,<div><br><div><div>On Mar 16, 2009, at 1:51 PM, Luke Evans wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">It is simpler. There is not any Mach-O envelope. The platform linker </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">can directly read Mach-O files as well as llvm bit-code file (using </div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">llvm bit-code file reader).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; min-height: 16px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">><i> Not sure if/where the exact form of the Mach-O file that carries bit </i></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Courier; ">><i> code is documented.</i></div></blockquote></div><div><br></div><div>Thanks for that. Yes, I see what you mean (no Mach-O envelope), yet there seems to be something fundamentally different between a bit-code file I create from Apple's llvm-gcc-4.2, and one created from the LLVM APIs.</div><div>Particularly:</div><div>- ld won't consume the/a bit-code file that is directly generated by the LLVM APIs: "ld warning: in foo.bc, file is not of required architecture"</div><div>- The bit-code file I have from LLVM differs from ones generated by Apple's llvm-gcc-4.2. The latter has a "DE C0 17 0B" magic introducer, and there seems to be another 16 bytes before the "BC Code" (42 43 C0 DE) magic appears.</div><div>Whereas, the file generated from the LLVM APIs starts immediately with the "BC Code" magic number.</div></div></div></blockquote><div><br></div>Yes. If you set the target as darwin for the module while generating bit-code file from the LLVM APIs then llvm bit-code writer will add this. </div><div><br></div><div>See llvm/lib/Bitcode/Writer/BitcodeWriter.cpp for more info.</div><div><br></div><div><div>1292 /// EmitDarwinBCHeader - If generating a bc file on darwin, we have to emit a</div><div>1293 /// header and trailer to make it compatible with the system archiver. To do</div></div><div><div>1294 /// this we emit the following header, and then emit a trailer that pads the</div><div>1295 /// file out to be a multiple of 16 bytes.</div><div>1296 ///</div><div>1297 /// struct bc_header {</div><div>1298 /// uint32_t Magic; // 0x0B17C0DE</div><div>1299 /// uint32_t Version; // Version, currently always 0.</div><div>1300 /// uint32_t BitcodeOffset; // Offset to traditional bitcode file.</div><div>1301 /// uint32_t BitcodeSize; // Size of traditional bitcode file.</div><div>1302 /// uint32_t CPUType; // CPU specifier.</div><div>1303 /// ... potentially more later ...</div><div>1304 /// };</div><div>1305 enum {</div><div>1306 DarwinBCSizeFieldOffset = 3*4, // Offset to bitcode_size.</div><div>1307 DarwinBCHeaderSize = 5*4</div><div>1308 };</div><div>1309</div><div><br></div><div>and</div><div><br></div><div><div>1388 /// WriteBitcodeToStream - Write the specified module to the specified output</div><div>1389 /// stream.</div><div>1390 void llvm::WriteBitcodeToStream(const Module *M, BitstreamWriter &Stream) {</div><div>1391 // If this is darwin, emit a file header and trailer if needed.</div><div>1392 bool isDarwin = M->getTargetTriple().find("-darwin") != std::string::npos;</div><div>1393 if (isDarwin)</div><div>1394 EmitDarwinBCHeader(Stream, M->getTargetTriple());</div><div>1395 </div><div><br></div></div></div><div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><div>There's a really good chance that this is just a case of 'user error'. At the very least it seems to me that I'm not doing something that's required to emit bit-code files in the format that they are consumable by ld. Alternatively, there is some kind of wrapper that the llvm-gcc-4.2 tool produces around the basic bit-code, though not as you've pointed out, a Mach-O format.</div><div><br></div><div>FWIW, here are the first 24 bytes, up to and including what I recognise as the LLVM bit-code magic number:</div><div>DE C0 17 0B 00 00 00 00 14 00 00 00 AC 01 00 00 07 00 00 00 <font class="Apple-style-span" color="#FF1E01">42 43 C0 DE</font>...</div><div><br></div><div>The 'file' util identifies this as "Compiled PSI (v1) data", though that's probably not relevant/useful, as it just comes from the DE C0, which could be any number of things.</div><div><br></div><div>Anyway, I guess my simple question is:</div><div>What do I need to do to get home-brew bit-code output from the LLVM bit-code writer to conform to whatever requirements that ld has for input?</div><div><br></div><div><br></div></div></div></blockquote></div></div></body></html>