llvm dev - Mar 2009 - [LLVMdev] n00b question: From module/bitcode to Mach-O dylib file directly?

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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/740f569b/attachment.html>

Can you tell me exactly what your command line is?

2009/3/16 Luke Evans <luke at eversosoft.com>:
>
> 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 ;-)
> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/9cc4b23b/attachment.html>

On Mar 16, 2009, at 1:56 AM, Luke Evans wrote:
> 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).
> Not sure if/where the exact form of the Mach-O file that carries bit  
> code is documented.
-
Devang

> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/a6463c02/attachment.html>