Dietmar Ebner
2009-Mar-12 10:17 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote:> The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).I've been successfully experimenting with an arm-softfloat-linux-gnu cross-compiler at the time of llvm 2.1. The easiest way to get this working is to use Dan Kegel's crosstool to build a regular gcc toolchain. This will give you binutils, libgcc, and glibc, which you will need anyway. Building llvm-gcc was relatively painless. The only problem I've encountered was that my target had no hardware floating point support and the endianess for the softfloat implementation (libgcc) differed from integer endianess, which required some patches at the llvm side. I have not checked if this is still necessary. If you run into the same problems, I would be happy to share the patch (which I have updated to llvm 2.4 at some point). - Dietmar [1] http://www.kegel.com/crosstool/ --------------------------------------------------------------------- Dietmar Ebner CD Laboratory - Compilation Techniques for Embedded Processors Institut fuer Computersprachen E: ebner at complang.tuwien.ac.at Technische Universitaet Wien T: (+431) 58801-58521 Argentinierstrasse 8 / E1851 F: (+431) 58801-18598 1040 Wien, Austria W: www.complang.tuwien.ac.at/cd/ebner
Misha Brukman
2009-Mar-12 15:30 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote:> On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't been able to reproduce the build using his instructions > > (I'll post my results in another thread). > > I've been successfully experimenting with an arm-softfloat-linux-gnu > cross-compiler at the time of llvm 2.1. The easiest way to get this > working is to use Dan Kegel's crosstool to build a regular gcc > toolchain. This will give you binutils, libgcc, and glibc, which you > will need anyway.I've been trying to build for the target arm-none-linux-gnueabi, using the appropriate pre-built CodeSourcery toolchain, hence avoiding building my own gcc crosstool prior to starting building LLVM and LLVM-GCC. LLVM builds just fine, it's building llvm-gcc that gives me this error: gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../../src/llvm-gcc4.2-2.5.source/gcc -I../../../../src/llvm-gcc4.2-2.5.source/gcc/build -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../include -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libcpp/include -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber -I/tmp/llvm-project/install/x86_64-arm/llvm/include -I/tmp/llvm-project/src/llvm-2.5/include -DENABLE_LLVM -I/tmp/llvm-project/install/x86_64-arm/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -o build/gencondmd.o build/gencondmd.c ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) This tells me there are some Darwin-specific bits in arm.md which shouldn't be there (MachO is Mac OS X-specific). I'm using the attached script llvm-arm-crosstool.sh to configure/build/install LLVM and LLVM-GCC from the 2.5 release. If anyone wants to try it out and see if it works for them, I'd love to hear their experiences. If any ARM/GCC experts know how to fix arm.md to not refer to Darwin-specific macros, that would be great, too. Building llvm-gcc was relatively painless. The only problem I've> encountered was that my target had no hardware floating point support > and the endianess for the softfloat implementation (libgcc) differed > from integer endianess, which required some patches at the llvm side. > I have not checked if this is still necessary. If you run into the > same problems, I would be happy to share the patch (which I have > updated to llvm 2.4 at some point).I would be interested in seeing your patch, if you wouldn't mind sharing it. Bonus points if you have a script similar to mine above to simplify the entire process, or your notes/directions that I can convert into an easy-to-run script. :-) Thanks, Misha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/c482b5cc/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-arm-crosstool.sh Type: application/x-sh Size: 4874 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/c482b5cc/attachment.sh>
Dale Johannesen
2009-Mar-12 17:08 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Mar 12, 2009, at 8:30 AMPDT, Misha Brukman wrote:> > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: > error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) > > This tells me there are some Darwin-specific bits in arm.md which > shouldn't be there (MachO is Mac OS X-specific). I'm using the > attached script llvm-arm-crosstool.sh to configure/build/install > LLVM and LLVM-GCC from the 2.5 release. If anyone wants to try it > out and see if it works for them, I'd love to hear their experiences. > > If any ARM/GCC experts know how to fix arm.md to not refer to Darwin- > specific macros, that would be great, too.Probably the right general idea is to #define MACHO_DYNAMIC_NO_PIC_P to be 0 for non-Darwin targets. Not sure where to put this so it will work for both targets (the Darwin definition comes from config/ darwin.h). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/ccdae5d1/attachment.html>
Evan Cheng
2009-Mar-12 17:54 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
We absolutely need someone to drive this. Some of us who work on the ARM target are developing and testing our work on proprietary platforms. We can't share our infrastructure with the public. It would be nice if someone can figure out the following and document them: 1. How to build llvm-gcc with ARM for various platforms? 2. How to use llvm-gcc to run llvm test suite on qemu, or some other ARM based netbooks. 3. Anything else of interest. :-) Would someone step up and drive this please? Thanks, Evan On Mar 12, 2009, at 8:30 AM, Misha Brukman wrote:> On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at > > wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't been able to reproduce the build using his instructions > > (I'll post my results in another thread). > > I've been successfully experimenting with an arm-softfloat-linux-gnu > cross-compiler at the time of llvm 2.1. The easiest way to get this > working is to use Dan Kegel's crosstool to build a regular gcc > toolchain. This will give you binutils, libgcc, and glibc, which you > will need anyway. > > I've been trying to build for the target arm-none-linux-gnueabi, > using the appropriate pre-built CodeSourcery toolchain, hence > avoiding building my own gcc crosstool prior to starting building > LLVM and LLVM-GCC. LLVM builds just fine, it's building llvm-gcc > that gives me this error: > > gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite- > strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H - > DGENERATOR_FILE -I. -Ibuild -I../../../../src/llvm-gcc4.2-2.5.source/ > gcc -I../../../../src/llvm-gcc4.2-2.5.source/gcc/build -I../../../../ > src/llvm-gcc4.2-2.5.source/gcc/../include -I../../../../src/llvm- > gcc4.2-2.5.source/gcc/../libcpp/include -I../../../../src/llvm- > gcc4.2-2.5.source/gcc/../libdecnumber -I../libdecnumber -I/tmp/llvm- > project/install/x86_64-arm/llvm/include -I/tmp/llvm-project/src/ > llvm-2.5/include -DENABLE_LLVM -I/tmp/llvm-project/install/x86_64- > arm/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS - > D__STDC_CONSTANT_MACROS -o build/gencondmd.o build/gencondmd.c > > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: > error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) > > This tells me there are some Darwin-specific bits in arm.md which > shouldn't be there (MachO is Mac OS X-specific). I'm using the > attached script llvm-arm-crosstool.sh to configure/build/install > LLVM and LLVM-GCC from the 2.5 release. If anyone wants to try it > out and see if it works for them, I'd love to hear their experiences. > > If any ARM/GCC experts know how to fix arm.md to not refer to Darwin- > specific macros, that would be great, too. > > Building llvm-gcc was relatively painless. The only problem I've > encountered was that my target had no hardware floating point support > and the endianess for the softfloat implementation (libgcc) differed > from integer endianess, which required some patches at the llvm side. > I have not checked if this is still necessary. If you run into the > same problems, I would be happy to share the patch (which I have > updated to llvm 2.4 at some point). > > I would be interested in seeing your patch, if you wouldn't mind > sharing it. Bonus points if you have a script similar to mine above > to simplify the entire process, or your notes/directions that I can > convert into an easy-to-run script. :-) > > Thanks, > Misha > <llvm-arm-crosstool.sh>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090312/b052a429/attachment.html>
Sandeep Patel
2009-Mar-13 00:39 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
Attached is the patch I've been building arm-eabi with, which might help with linux-gnueabi. I disable multilib to get around several bugs with thumb. I build cross binutils first, then llvm, then llvm-gcc with newlib merged in. The following bugs need to be addressed for these non-Darwin ARM targets: 1388 2313 2545 2985 deep On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at gmail.com> wrote:> On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at> > wrote: >> >> On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: >> > The problem I've had is building an LLVM cross-compiler from Linux/ >> > x86 to Linux/ARM (as has another llvm-dev poster). Someone >> > mentioned to me off-list that he managed to get it to build, but I >> > haven't been able to reproduce the build using his instructions >> > (I'll post my results in another thread). >> >> I've been successfully experimenting with an arm-softfloat-linux-gnu >> cross-compiler at the time of llvm 2.1. The easiest way to get this >> working is to use Dan Kegel's crosstool to build a regular gcc >> toolchain. This will give you binutils, libgcc, and glibc, which you >> will need anyway. > > I've been trying to build for the target arm-none-linux-gnueabi, using the > appropriate pre-built CodeSourcery toolchain, hence avoiding building my own > gcc crosstool prior to starting building LLVM and LLVM-GCC. LLVM builds > just fine, it's building llvm-gcc that gives me this error: > > gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -DGENERATOR_FILE > -I. -Ibuild -I../../../../src/llvm-gcc4.2-2.5.source/gcc > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/build > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../include > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libcpp/include > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libdecnumber > -I../libdecnumber -I/tmp/llvm-project/install/x86_64-arm/llvm/include > -I/tmp/llvm-project/src/llvm-2.5/include -DENABLE_LLVM > -I/tmp/llvm-project/install/x86_64-arm/llvm/include -D_DEBUG -D_GNU_SOURCE > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -o build/gencondmd.o > build/gencondmd.c > > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: error: > ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function) > > This tells me there are some Darwin-specific bits in arm.md which shouldn't > be there (MachO is Mac OS X-specific). I'm using the attached script > llvm-arm-crosstool.sh to configure/build/install LLVM and LLVM-GCC from the > 2.5 release. If anyone wants to try it out and see if it works for them, > I'd love to hear their experiences. > > If any ARM/GCC experts know how to fix arm.md to not refer to > Darwin-specific macros, that would be great, too. > >> Building llvm-gcc was relatively painless. The only problem I've >> encountered was that my target had no hardware floating point support >> and the endianess for the softfloat implementation (libgcc) differed >> from integer endianess, which required some patches at the llvm side. >> I have not checked if this is still necessary. If you run into the >> same problems, I would be happy to share the patch (which I have >> updated to llvm 2.4 at some point). > > I would be interested in seeing your patch, if you wouldn't mind sharing > it. Bonus points if you have a script similar to mine above to simplify the > entire process, or your notes/directions that I can convert into an > easy-to-run script. :-) > > Thanks, > Misha > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- A non-text attachment was scrubbed... Name: fix_apples_bugs.diff Type: application/octet-stream Size: 3483 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090313/ade9bc25/attachment.obj>
Dietmar Ebner
2009-Mar-16 14:22 UTC
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Mar 12, 2009, at 4:30 PM, Misha Brukman wrote:> I've been trying to build for the target arm-none-linux-gnueabi, > using the appropriate pre-built CodeSourcery toolchain, hence > avoiding building my own gcc crosstool prior to starting building > LLVM and LLVM-GCC. LLVM builds just fine, it's building llvm-gcc > that gives me this error: > [...] > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788: > error: ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function)I think this error is a result of the switch to Appel's gcc 4.2. I cannot say if it's hard to fix these issues (I guess not), but if you need a quick solution, you might sill use the 4.0 based frontend. As far as I know, the bitcode format should be compatible to the current tools (somebody please correct me if I'm wrong).> Building llvm-gcc was relatively painless. The only problem I've > encountered was that my target had no hardware floating point support > and the endianess for the softfloat implementation (libgcc) differed > from integer endianess, which required some patches at the llvm side. > I have not checked if this is still necessary. If you run into the > same problems, I would be happy to share the patch (which I have > updated to llvm 2.4 at some point). > > I would be interested in seeing your patch, if you wouldn't mind > sharing it. Bonus points if you have a script similar to mine above > to simplify the entire process, or your notes/directions that I can > convert into an easy-to-run script. :-)Sorry, there's no such script. But here's how I configured llvm-gcc: configure --prefix=<wherever> --program-prefix=llvm-arm- --enable- llvm=<path to llvm> --enable-checking --target=arm-softfloat-linux-gnu --disable-shared --disable-nls --disable-threads --with-float=soft -- enable-languages=c You can find a tiny patch for llvm-gcc and the necessary changes for llvm 2.4 attached. The llvm patch should cleanly apply to llvm 2.4, but I had to pick the changes from a private repository with some modifications. Thus, the patch is untested and I cannot guarantee if I got all the necessary bits. Feel free to contact me if you run into troubles. The patch allows to have different endianess for integer and floating point types. I'm not sure if this is the best way to handle this issue, but at least it seems to be working (I've used it to cross- compile SPECINT 2000). Note that you probably won't need all this if you have a hardware FPU. Best, - Dietmar -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-gcc.patch Type: application/octet-stream Size: 2055 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/c314203a/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm2.4-softfloat.patch Type: application/octet-stream Size: 10648 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/c314203a/attachment-0001.obj> -------------- next part -------------- --------------------------------------------------------------------- Dietmar Ebner CD Laboratory - Compilation Techniques for Embedded Processors Institut fuer Computersprachen E: ebner at complang.tuwien.ac.at Technische Universitaet Wien T: (+431) 58801-58521 Argentinierstrasse 8 / E1851 F: (+431) 58801-18598 1040 Wien, Austria W: www.complang.tuwien.ac.at/cd/ebner
Maybe Matching Threads
- [LLVMdev] Consumer ARM platform suitable for LLVM development?
- [LLVMdev] Consumer ARM platform suitable for LLVM development?
- [LLVMdev] Consumer ARM platform suitable for LLVM development?
- [LLVMdev] Consumer ARM platform suitable for LLVM development?
- [LLVMdev] Consumer ARM platform suitable for LLVM development?