n00b question: From module/bitcode to Mach-O dylib file directly?

Project Infrastructure LLVM Dev List Archives
1

Hey Luke,

Unfortunately, the ‘state of the art’ is that llc only really supports
emission of native assembly files (-filetype=asm) which can then be
assembled and linked with your native gas/ld.

There is some source support for ‘object file generation’, exposed via
the -filetype=obj flag to llc, but it is not complete, and totally
broken in some cases. This is something I am trying to work on with
Aaron. You can follow our discussion on the list here, and feel free
to pitch in.

That said, the MachO generation should work (in 2.5) for outputting
.o files, which would still need to be linked using your native ld
into a dynlib. I don’t see that llc will ever generate a dynlib, as I
think that that is not its function. The most you can expect is a
valid target object file.

If you encounter a particular issue using the -filetype=obj flag,
please let us know so we can fix it…

I for one would really like to see object generation become a fully
working feature of the llvm toolchain.

Thanks for the scoop on the situation. Much obliged.
It’s some relief that my total failure to get anywhere this evening isn’t entirely down to my own incompetence :wink:

After failing to get llc working I was starting to steal code from it to create just the specific pipeline I wanted, but that wasn’t going anywhere either.

Anyway, actually getting .o output from llc (and via the API of course) would be wonderful. I did try the 2.5 llc I compiled myself with various combinations of arguments including things like:

llc -mtriple=‘i686-apple-darwin9’ -filetype=obj myModule.bc -o foo.o

…but that doesn’t seem to work at the moment either (same “target does not support generation of this file type!” message).

From what you say, it seems this should work in some simple cases for 2.5, so I conclude that I haven’t been driving llc correctly enough to get the output to work. Does it need a specific combination of args? Perhaps more in the module than I provide (targetTriple?).

I had managed to get a .s out by requesting the asm file type, so at the very least I can rely more of the platform tooling to achieve the result I want.

Hopefully you can provide more clue about getting llc going for .o output with 2.5. Otherwise, I’ll certainly keep watching progress with interest.

Cheers

– lwe

2

Can you tell me exactly what your command line is?

3

I for one would really like to see object generation become a fully
working feature of the llvm toolchain.

Actually, a related thing I’ve been curious about is the difference between the output of the llvm-gcc-4.2 front end on the Mac and a regular plain vanilla bit code file.
The former file can be named a .o and the platform linker now knows how to do LTO while linking against other BC-based and native files.
These are clearly slightly different to native Mach-O obj files, and using a hex editor you can see the bit code enclosed within them - presumably they use the Mach-O envelope but store the BC code in a different section to where native code would be.
Not sure if/where the exact form of the Mach-O file that carries bit code is documented.

A cool thing IMO would be a tool that wrapped an ordinary BC file in whatever envelope the llvm-gcc-4.2 tool puts around the bitcode, in addition to the method to generate a Mach-O file with the native code.

– lwe

4

Actually, a related thing I've been curious about is the difference between the output of the llvm-gcc-4.2 front end on the Mac and a regular plain vanilla bit code file.
The former file can be named a .o and the platform linker now knows how to do LTO while linking against other BC-based and native files.

Yes.

These are clearly slightly different to native Mach-O obj files, and using a hex editor you can see the bit code enclosed within them - presumably they use the Mach-O envelope but store the BC code in a different section to where native code would be.

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).

5

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.

Excellent. Thanks a lot for explaining that.

I was actually burning the target triple “i686-apple-darwin9” into my LLVM module, but perhaps that isn’t quite right, or enough, to get the correct output.
Anyway, I should be able to figure it out from here - thanks again.

– lwe