llvm dev - Apr 2010 - [LLVMdev] "clang -v" shows a GCC call

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.html
Is 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.