[LLVMdev] Bit-code file input to ld (was: ...From module/bitcode to Mach-O dylib file directly)

[Devang Patel]

Hi Luke,

On Mar 16, 2009, at 1:51 PM, Luke Evans wrote:

>> 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 fundamentally different between a bit- 
> code file I create from Apple's llvm-gcc-4.2, and one created from  
> the LLVM APIs.
> Particularly:
> - 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"
> - 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.
> Whereas, the file generated from the LLVM APIs starts immediately  
> with the "BC  Code" magic number.

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.

See llvm/lib/Bitcode/Writer/BitcodeWriter.cpp for more info.

1292 /// EmitDarwinBCHeader - If generating a bc file on darwin, we  
have to emit a
1293 /// header and trailer to make it compatible with the system  
archiver.  To do
1294 /// this we emit the following header, and then emit a trailer  
that pads the
1295 /// file out to be a multiple of 16 bytes.
1296 ///
1297 /// struct bc_header {
1298 ///   uint32_t Magic;         // 0x0B17C0DE
1299 ///   uint32_t Version;       // Version, currently always 0.
1300 ///   uint32_t BitcodeOffset; // Offset to traditional bitcode  
file.
1301 ///   uint32_t BitcodeSize;   // Size of traditional bitcode file.
1302 ///   uint32_t CPUType;       // CPU specifier.
1303 ///   ... potentially more later ...
1304 /// };
1305 enum {
1306   DarwinBCSizeFieldOffset = 3*4, // Offset to bitcode_size.
1307   DarwinBCHeaderSize = 5*4
1308 };
1309

and

1388 /// WriteBitcodeToStream - Write the specified module to the  
specified output
1389 /// stream.
1390 void llvm::WriteBitcodeToStream(const Module *M, BitstreamWriter  
&Stream) {
1391   // If this is darwin, emit a file header and trailer if needed.
1392   bool isDarwin = M->getTargetTriple().find("-darwin") !=  
std::string::npos;
1393   if (isDarwin)
1394     EmitDarwinBCHeader(Stream, M->getTargetTriple());
1395


>
> 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.
>
> FWIW, here are the first 24 bytes, up to and including what I  
> recognise as the LLVM bit-code magic number:
> DE C0  17 0B  00 00  00 00  14 00  00 00  AC 01  00 00  07 00  00  
> 00  42 43  C0 DE...
>
> 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.
>
> Anyway, I guess my simple question is:
> 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/789ef502/attachment.html>