One issue I've been looking at with regard to using LLVM as a compiler backend is distribution of programs, particularly on Linux where different distributions have different binary package formats and it is usual to ship programs as source rather than binary; specifically, I'm looking at the general case where the end user may not have (the correct version of) LLVM installed, so the compiler can't simply be run on the end user's machine. A solution that occurs to me is to compile as far as assembler on the programmer's machine, then ship the .s file (or a small number thereof, one per CPU architecture) and assemble it on the user's machine (which in most cases will have the GNU assembler installed). It seems to me that this ought to work; are there any pitfalls I should be aware of?
Russell Wallace wrote:> One issue I've been looking at with regard to using LLVM as a compiler > backend is distribution of programs, particularly on Linux where > different distributions have different binary package formats and it > is usual to ship programs as source rather than binary; specifically, > I'm looking at the general case where the end user may not have (the > correct version of) LLVM installed, so the compiler can't simply be > run on the end user's machine. > > A solution that occurs to me is to compile as far as assembler on the > programmer's machine, then ship the .s file (or a small number > thereof, one per CPU architecture) and assemble it on the user's > machine (which in most cases will have the GNU assembler installed). > It seems to me that this ought to work; are there any pitfalls I > should be aware of? >A potential problem with this approach is that different Linux systems have different versions of header files and libraries. While the machine code will assemble correctly, it may not link (because a native code library is missing or is of an incorrect version) or the generated code will not work properly (because some structure in a header file is different between the system used for compilation and the system on which the program is installed). Shipping assembly code is more or less equivalent to shipping a binary. If shipping native code will work, then shipping assembly code will work (in which case, why ship assembly code instead of a native binary?). -- John T.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Ah! Thanks, that's exactly what I needed to know (albeit was hoping not to hear :-)). Hmm, that actually kills every possible solution I can think of, so the good news is, it takes the problem off my to-do list (albeit via the 'unsolvable' route rather than the 'solved' route), and unless anyone else has a possible solution, I can take it off my to-do list :-) On Fri, Jan 29, 2010 at 7:51 PM, John Criswell <criswell at uiuc.edu> wrote:> Russell Wallace wrote: >> >> One issue I've been looking at with regard to using LLVM as a compiler >> backend is distribution of programs, particularly on Linux where >> different distributions have different binary package formats and it >> is usual to ship programs as source rather than binary; specifically, >> I'm looking at the general case where the end user may not have (the >> correct version of) LLVM installed, so the compiler can't simply be >> run on the end user's machine. >> >> A solution that occurs to me is to compile as far as assembler on the >> programmer's machine, then ship the .s file (or a small number >> thereof, one per CPU architecture) and assemble it on the user's >> machine (which in most cases will have the GNU assembler installed). >> It seems to me that this ought to work; are there any pitfalls I >> should be aware of? >> > > A potential problem with this approach is that different Linux systems have > different versions of header files and libraries. While the machine code > will assemble correctly, it may not link (because a native code library is > missing or is of an incorrect version) or the generated code will not work > properly (because some structure in a header file is different between the > system used for compilation and the system on which the program is > installed). > > Shipping assembly code is more or less equivalent to shipping a binary. If > shipping native code will work, then shipping assembly code will work (in > which case, why ship assembly code instead of a native binary?). > > -- John T. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >
Hello Russell, Major pitfall #1: LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. I've been looking forward to the day that LLVM can be used for cross-architecture development, myself. Thanks for asking, --Sam ----- Original Message ----> From: Russell Wallace <russell.wallace at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Fri, January 29, 2010 1:17:12 PM > Subject: [LLVMdev] Distribution in assembler format > > One issue I've been looking at with regard to using LLVM as a compiler > backend is distribution of programs, particularly on Linux where > different distributions have different binary package formats and it > is usual to ship programs as source rather than binary; specifically, > I'm looking at the general case where the end user may not have (the > correct version of) LLVM installed, so the compiler can't simply be > run on the end user's machine. > > A solution that occurs to me is to compile as far as assembler on the > programmer's machine, then ship the .s file (or a small number > thereof, one per CPU architecture) and assemble it on the user's > machine (which in most cases will have the GNU assembler installed). > It seems to me that this ought to work; are there any pitfalls I > should be aware of? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I don't think I quite understand this... suppose for example you're trying to use an LLVM-based toolchain running on an x86 PC to write code for a device that uses an ARM processor in big endian mode, so you tell the LLVM code generator "generate code for ARM, big endian"... are you saying the optimizer will actually assume the target device is little endian because the development system is little endian (which would of course break things)? On Fri, Jan 29, 2010 at 8:09 PM, Samuel Crow <samuraileumas at yahoo.com> wrote:> Hello Russell, > > Major pitfall #1: > LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been looking forward to the day that LLVM can be used for cross-architecture development, myself. > > Thanks for asking, > > --Sam > > > > ----- Original Message ---- >> From: Russell Wallace <russell.wallace at gmail.com> >> To: llvmdev at cs.uiuc.edu >> Sent: Fri, January 29, 2010 1:17:12 PM >> Subject: [LLVMdev] Distribution in assembler format >> >> One issue I've been looking at with regard to using LLVM as a compiler >> backend is distribution of programs, particularly on Linux where >> different distributions have different binary package formats and it >> is usual to ship programs as source rather than binary; specifically, >> I'm looking at the general case where the end user may not have (the >> correct version of) LLVM installed, so the compiler can't simply be >> run on the end user's machine. >> >> A solution that occurs to me is to compile as far as assembler on the >> programmer's machine, then ship the .s file (or a small number >> thereof, one per CPU architecture) and assemble it on the user's >> machine (which in most cases will have the GNU assembler installed). >> It seems to me that this ought to work; are there any pitfalls I >> should be aware of? >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > >
On Jan 29, 2010, at 12:09 PM, Samuel Crow wrote:> Hello Russell, > > Major pitfall #1: > LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been looking forward to the day that LLVM can be used for cross-architecture development, myself.FYI, http://llvm.org/docs/FAQ.html#platformindependent applies to clang just as much as llvm-gcc. Dan