Re: [avr-llvm-devel] Toolchain support needed!

[Borja F. <bor...@gm...>]

Hi Eric, welcome back!

Basically the situation is what I wrote in my previous email. We need to
get a very basic toolchain working so we can complete the path from the .c
to a .hex file. The backend should be able to compile any C code by now,
except for new bugs and inline asm. If we're able to compile larger
projects with the toolchain then we'll be able to detect more bugs and get
a more reliable backend faster.

Currently, clang+llc (llc is the program that does the LLVM IR to AVR asm
conversion) is able to compile C code to .S text asm files. The missing
steps have to be done by avr-gcc, this is: generating the object files,
linking them and generating hex files.
My current setup is (under linux): an avr-gcc+avr-libc installation as
described in the avr-libc manual, and a llvm installation, both in separate
folders.

If you run this cmd line: clang -O3 test.c -o test.o -ccc-host-triple
avr-generic-generic -ccc-gcc-name avr-gcc -mmcu=avr5
clang drives llc to generate the .S file, then with the -ccc-gcc-name
avr-gcc param it calls avr-gcc passing that new generated .S file so it can
be converted to an object file with the help of the mmcu param indicating
for what mcu we're compiling.
avr-gcc has some logic inside where to drive the assembler and linker
depending on the mmcu param it will call the linker with different options,
for example the crt files involved. This is why for now we need avr-gcc,
it's used as a driver for the linker and the assembler. Of course in the
future we should be able to generate .o ELF files and an integrated
assembler with llvm, but that will come later when we have a more mature
backend.

One important thing is that clang has to use avr-libc's include files not
the system's defaults, now when I include stdio.h it's using the linux
header file, not the avr specific one. So obviously this has to be fixed,
but we need to know first where these files are going to be placed in our
toolchain, i guess as a quick hack using the -I param could do it, but in
avr-gcc nobody uses it, so we shouldn't add more complexity to the cmd line.

If you need any other details, explanation or something I missed out let me
know.

2012/9/7 Weddington, Eric <Eri...@at...>

> Hi Borja!
>
> Sorry to respond late to this email...
>
> This is really exciting!
>
> You said you need help in getting a basic toolchain working. Help me
> understand in detail, what you have, and where you want to be.
>
> We need avr-gcc to run the assembler and linker. From avr-llvm, we have a
> compiler that will compile C to assembler. I would think that we would need
> to modify the avr-gcc specs to call the correct (new) executable for the
> compilation step.
>
> If you can give me a few more details on your setup, then let's see where
> we can go with it. :-)
>
> Eric
>
> > -----Original Message-----
> > From: Borja Ferrer [mailto:bor...@gm...]
> > Sent: Tuesday, August 28, 2012 4:24 PM
> > To: avr...@li...
> > Subject: [avr-llvm-devel] Toolchain support needed!
> >
> > Hello,
> >
> > With the latest changes, the backend is reaching the point where it can
> > compile nearly any sort of code. One thing that is missing is support for
> > inline asm which is heavily used in avr-libc, but apart from that it
> should be
> > able to compile the rest. With a few tweaks i've been able to compile a
> 2200
> > line C file that stresses floating point calculations that produces
> around 22k
> > instructions (C file -> S file)
> >
> > Now I'm getting more interested on getting a very basic toolchain
> working,
> > Eric we'll need your help here. I've been able to build from a C file to
> a hex
> > file a very basic main() function. avr-gcc is needed to produce the elf
> files
> > and to drive the linker, so we'll have to stick with it for a while. The
> setup
> > I have is messy because avr-gcc is in one folder with avr-libc and clang
> and
> > llvm in another, so in order to get the toolchain with a decent setup
> both
> > things should be in the same folder. Also included files default to the
> > system's not the avr specific ones. Maybe others have tried it before,
> so i
> > want to know how you did it or how hard it was, but in my case my first
> try
> > was yesterday.
> >
> > Also I'm going to change how register-pairs are represented because
> avr-as
> > can't understand what r29:r28 is. The llvm asm writer needs a bit of
> tweaking
> > because avr-as can't understand some asm directives it produces.
> >
> > This is the cmd line i'm using to generate an object file: clang -O3
> test.c -o
> > test.o -ccc-host-triple avr-generic-generic -ccc-gcc-name avr-gcc
> -mmcu=avr5
> > notice that avr-gcc is passed so that clang can drive it once the .S
> file is
> > generated.
> >
> > So try compiling a trivial main function to get the hex file generated,
> you'll
> > need avr-copy (provided by binutils) to convert the elf file to hex, but
> that
> > is easily handled by makefiles. Also people using windows try doing it
> aswell
> > since I dont have a setup for it and I'm looking forward for it.
> >
> > Once we get the basic toolchain working, adding support for avr-libc and
> > linking programs with its libraries should be much easier. I look
> forward for
> > any help here!
>
>