Thanks for your really fast answer. I understood that, but this means that the llvm+Clang suite is not able to create a machine binary file without any intervention of GCC ? I thought it could. This means too that I must port GCC+Binutils in order to have a LLVM port for my architecture ? That sound like a huge work, I've chosen LLVM at the beginnig because I thought it could avoid me porting GCC+Binutils. Thanks for the reply. Jim Grosbach wrote:> > llvm (and clang) do not include binutils. You're seeing clang invoking the > gcc shell to assemble the .s file that clang generated, then again to link > the object file into an executable. > > On Apr 27, 2010, at 8:31 AM, Swiss Guy wrote: > >> >> Hi everyone, >> >> I'm very new to the world of compilation and I've got to spend some time >> time on LLVM. >> As I have to produce a cross compiler for a completely new target and I >> don't want to cross-build the binutils, I choose Clang as a replacement >> frontend for llvm instead of llvm-gcc. >> >> But first, I just would like to compile something on my Linux platform in >> order to test the software, no question about cross-compiling at the >> moment. >> The only problem is that every time I try to compile using the command >> below, I get this result telling me that Clang is calling gcc instead of >> all >> the LLVM tools >> >> Here's the command and the result (I skipped a line at each GCC call): >> >> >> $clang -v hello.c >> >> clang version 1.0 >> (https://llvm.org/svn/llvm-project/cfe/branches/release_26 >> exported) >> Target: i386-pc-linux-gnu >> Thread model: posix >> "/bin/clang-cc" -triple i386-pc-linux-gnu -S -disable-free >> -main-file-name >> main.c --relocation-model static --disable-fp-elim --unwind-tables=0 >> --mcpu=pentium4 --fmath-errno=1 -v -fdiagnostics-show-option -o >> /tmp/cc-G6QVZj.s -x c main.c >> clang-cc version 1.0 based upon llvm 2.6 hosted on i686-pc-linux-gnu >> ignoring nonexistent directory "/System/Library/Frameworks" >> ignoring nonexistent directory "/Library/Frameworks" >> #include "..." search starts here: >> #include <...> search starts here: >> /lib/clang/1.0/include >> /usr/include >> End of search list. >> >> "/usr/bin/gcc" -v -c -m32 -o /tmp/cc-J586JU.o -x assembler >> /tmp/cc-G6QVZj.s >> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs >> Configured with: ../configure --verbose --program-suffix=-3 --prefix=/usr >> --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib >> --libexecdir=/usr/lib >> --mandir=/usr/share/man --infodir=/usr/share/info >> --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls >> --without-included-gettext --enable-version-specific-runtime-libs >> --without-x --enable-libgcj --disable-java-awt --with-system-zlib >> --enable-interpreter --disable-libgcj-debug --enable-threads=posix >> --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions >> --enable-hash-synchronization --enable-libstdcxx-debug >> Thread model: posix >> gcc version 3.4.4 (Red Hat 3.4.4) >> as -o /tmp/cc-J586JU.o /tmp/cc-G6QVZj.s >> >> "/usr/bin/gcc" -v -m32 -o a.out /tmp/cc-J586JU.o >> Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs >> Configured with: ../configure --verbose --program-suffix=-3 --prefix=/usr >> --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib >> --libexecdir=/usr/lib >> --mandir=/usr/share/man --infodir=/usr/share/info >> --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls >> --without-included-gettext --enable-version-specific-runtime-libs >> --without-x --enable-libgcj --disable-java-awt --with-system-zlib >> --enable-interpreter --disable-libgcj-debug --enable-threads=posix >> --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions >> --enable-hash-synchronization --enable-libstdcxx-debug >> Thread model: posix >> gcc version 3.4.4 (Red Hat 3.4.4) >> collect2 -Bdynamic --dll-search-prefix=cyg -o a.out >> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o >> -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 >> -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. >> /cygdrive/c/Users/lbonnet/AppData/Local/Temp/cc-J586JU.o -lgcc -lcygwin >> -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc >> >> >> Excuse me if I wrote something stupid or just forgetting something. Just >> tell me what's wrong. >> >> Thanks in advance. >> -- >> View this message in context: >> http://old.nabble.com/%22clang--v%22-shows-a-GCC-call-tp28378453p28378453.html >> Sent from the LLVM - Dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- View this message in context: http://old.nabble.com/%22clang--v%22-shows-a-GCC-call-tp28378453p28378742.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
On 04/27/2010 06:54 PM, Swiss Guy wrote:> > Thanks for your really fast answer. > > I understood that, but this means that the llvm+Clang suite is not able to > create a machine binary file without any intervention of GCC ? > > I thought it could. > > This means too that I must port GCC+Binutils in order to have a LLVM port > for my architecture ? > > That sound like a huge work, I've chosen LLVM at the beginnig because I > thought it could avoid me porting GCC+Binutils.You can define your own toolchain in clang. I think FreeBSD does that. You need an assembler, a linker, and a way to call them. It doesn't necesarely have to be binutils assembler, but it must understand gas syntax (maybe clang -integrated-as can help here?). Best regards, --Edwin.
On 4/27/10 9:54 AM, Swiss Guy wrote:> > Thanks for your really fast answer. > > I understood that, but this means that the llvm+Clang suite is not able to > create a machine binary file without any intervention of GCC ?Not yet. We're working on it, though: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html
On Apr 27, 2010, at 8:54 AM, Swiss Guy wrote:> > Thanks for your really fast answer. > > I understood that, but this means that the llvm+Clang suite is not able to > create a machine binary file without any intervention of GCC ? > > I thought it could.There are two answers. 1) we're in the process of building a new llvm-native assembler. When this is done, LLVM will be able to produce .o files without any other tools. 2) clang can talk directly to a system assembler if you teach it how to (by defining a "ToolChain" for your platform). In the absence of that, it uses GCC as an abstraction layer to make it more portable. In the short term, I'd recommend adding a clang toolchain description for your target. This is pretty easy to do, ask on the cfe-dev list for more details. -Chris
On Tue, 27 Apr 2010 10:22:49 -0600, Charles Davis <cdavis at mymail.mines.edu> wrote:> Not yet. We're working on it, though: > > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.htmlIs anyone actively working on adding ELF object file support to the MC project?
Thanks a lot for all your answers, now I think I understand how the infrastructure works. There's a pretty good community here, this is really cool ! I think I'm going to port the binutils for my architecture in order to have an assembler and a linker, and stay with CLang+LLVM to generate native asembler. ( *.s file ) Thank you all again, and keep up the good work ! Török Edwin wrote:> > On 04/27/2010 06:54 PM, Swiss Guy wrote: >> >> Thanks for your really fast answer. >> >> I understood that, but this means that the llvm+Clang suite is not able >> to >> create a machine binary file without any intervention of GCC ? >> >> I thought it could. >> >> This means too that I must port GCC+Binutils in order to have a LLVM port >> for my architecture ? >> >> That sound like a huge work, I've chosen LLVM at the beginnig because I >> thought it could avoid me porting GCC+Binutils. > > You can define your own toolchain in clang. I think FreeBSD does that. > You need an assembler, a linker, and a way to call them. > > It doesn't necesarely have to be binutils assembler, but it must > understand gas syntax (maybe clang -integrated-as can help here?). > > Best regards, > --Edwin. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >=)=)=) -- View this message in context: http://old.nabble.com/%22clang--v%22-shows-a-GCC-call-tp28378453p28385949.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
Török Edwin a écrit :> On 04/27/2010 06:54 PM, Swiss Guy wrote: >> Thanks for your really fast answer. >> >> I understood that, but this means that the llvm+Clang suite is not able to >> create a machine binary file without any intervention of GCC ? >> >> I thought it could. >> >> This means too that I must port GCC+Binutils in order to have a LLVM port >> for my architecture ? >> >> That sound like a huge work, I've chosen LLVM at the beginnig because I >> thought it could avoid me porting GCC+Binutils. > > You can define your own toolchain in clang. I think FreeBSD does that. > You need an assembler, a linker, and a way to call them. > > It doesn't necesarely have to be binutils assembler, but it must > understand gas syntax (maybe clang -integrated-as can help here?). >You can also use LLVMC driver to easily define your own build flow. see llvm/tools/llvmc/example/ directory and llvmc tutorial in llvm documentation. (and don't mix up llvmc and llvm-mc that's different tools) But you need your own assembler/linker and the easiest way to have this is to port binutils. You don't have to port GCC, only binutils is required.
Seemingly Similar Threads
- [LLVMdev] "clang -v" shows a GCC call
- [LLVMdev] "clang -v" shows a GCC call
- [LLVMdev] "clang -v" shows a GCC call
- [LLVMdev] [GSoC] "Microsoft Direct3D shader bytecode backend" proposal
- [LLVMdev] Where does LLVM mangle characters from llvm-ir names while generating native code?