Hi Brian, Thanks for sharing your experience with dragonegg. I would like to use tilera-gcc as the compiler driver. native gcc would not be able to handle things like tilera specific intrinsics in the source code. I built dragonegg using GCC=/path/to/tilera-gcc48/bin/tile-gcc LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make and also tried only emitting the IR /path/to/tilera-gcc48/bin/tile-gcc -fplugin=/path/to/dragonegg.so -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c (and still get the error: cannot load plugin dragonegg.so: wrong ELF class: ELFCLASS64 ) - Ajay On Mon, Oct 27, 2014 at 9:39 PM, Brian Faull <bfaull at cog-e.com> wrote:> Hello, > > There may be plenty more experienced experts on DragonEgg (and hopefully > they'll correct me if I'm wrong), but I figured I'd chime in with my brief > experience to start. I have messed with this a bit, and DragonEgg has > worked for my experiments. Your configuration has many things that are > different than mine; however, I think you might simply have the > cross-compilers crossed backward; I think you want to use your native gcc > as compiler-driver; pass dragonegg.so to your native-gcc rather than > tilera-gcc. I think you may simply need to do the following: > > 1- Build DragonEgg using your system compiler (or gcc 4.6.4 as recommended > on dragonegg.llvm.org); when doing `make`, point explicitly at your > *build* (x86_64) GCC of choice, and against your *target* (tilera) > `llvm-config`. > 2- use your x86_64 compiler-driver as front-end, which due to the magic of > DragonEgg and llvm-config will use your target LLVM backend. > > Or it could be really late and I'm not thinking straight. :) > > More detail: > I had to set a few non-obvious (to me) things in the build and use > process, so I'll reflect them here for you and/or posterity. You will need > all three components though: LLVM backend for your architecture (tilera) > I'd suggest a few things to try, in order for you to find a configuration > that works for you: > > * Sounds like you're on x86_64 / AMD64. I'd suggest to start with > building the simplest configuration: using your system compiler to build > everything for your system native architecture, and this will be the > easiest configuration to debug. > > * According to the dragonegg.llvm.org web site, DragonEgg works best with > GCC 4.6. You may wish to try that (I recommend looking at > http://gcc.gnu.org/gcc-4.6/ for GCC 4.6.4, which is the latest release of > that version). I don't know exactly why this version is said to work best; > perhaps the DragonEgg site is simply stale. I bootstrapped a clean, native > version of 4.6.4 without much headache. > > * Since I wanted to get DragonEgg built to work with GCC4.6.4, I built > DragonEgg with GCC4.6.4. IIRC, the DragonEgg makefile wants you to specify > the compiler as GCC=... rather than CC=... but it looks like it should eat > both. Also, I read somewhere that LLVM3.3's llvm-config had some behavior > that argues with DragonEgg. Contrary to best practice "build outside the > source tree" so as to prevent polluting of the source tree, I saw a > recommendation to build *within* the source tree, so I rolled back and > built LLVM3.3 *in the source tree* (GASP!) for native (x86_64). In sum, to > build DragonEgg I used something like > GCC=/path/to/gcc464/bin/gcc > LLVM_CONFIG=/path/to/llvm-3.3.src-x86_64/prefix/bin/llvm-config make > > * Then to use this shiny new .so, I started by going only up to the point > of emitting LLVM IR so as not to confuse the situation with further > architecture-specific compilation/assembly: > /path/to/gcc464/bin/gcc -fplugin=/path/to/dragonegg.so > -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c > I also chose to specify the full path of dragonegg.so, so I didn't have to > be concerned with library paths. > > Then you should be able to manually use your backend (llvm33/bin/llc, > assembler, etc.) to generate an architecture-specific object. Once you've > got all those components, you should be able to get everything integrated > with just one gcc compiler-driver invocation. > > HTH, > Brian > > > > > On Oct 27, 2014, at 11:53 PM, Ajay Panyala <ajay.panyala at gmail.com> wrote: > > I am using a gcc (v 4.8.2) cross compiler for the tilera architecture. > There is an LLVM (v 3.3) cross compiler available for tilera ( > http://tilera.github.io/llvm), > but the frontend only has partial support for certain tilera intrinsics > and no OpenMP support. > > Hence, I have decided to use DragonEgg (v 3.3) to resolve this. I was able > to build > DragonEgg, but when I pass the command line argument -fplugin=dragonegg.so > when compiling with the tilera-gcc I get the error > cannot load dragonegg.so: wrong ELF class: ELFCLASS64 > i.e. the tilera-gcc does not accept the x86 shared library object > dragonegg.so > > The dragonegg sources were built using the x86 GCC, but the plugin > was built to load into the tilera gcc. > > Could someone please point out what I am missing here. > > Thanks > Ajay > _______________________________________________ > 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/20141028/9375eae4/attachment.html>
Anton Korobeynikov
2014-Oct-28 18:01 UTC
[LLVMdev] DragonEgg3.3 support for gcc cross compilers
Looks like your gcc is 32-bit and you're trying to load 64-bit plugin. On Tue, Oct 28, 2014 at 8:27 PM, Ajay Panyala <ajay.panyala at gmail.com> wrote:> Hi Brian, > > Thanks for sharing your experience with dragonegg. > I would like to use tilera-gcc as the compiler driver. native gcc would not > be able to > handle things like tilera specific intrinsics in the source code. > > I built dragonegg using > > GCC=/path/to/tilera-gcc48/bin/tile-gcc > LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make > > and also tried only emitting the IR > > /path/to/tilera-gcc48/bin/tile-gcc -fplugin=/path/to/dragonegg.so > -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c > > (and still get the error: cannot load plugin dragonegg.so: wrong ELF class: > ELFCLASS64 ) > > - Ajay > > On Mon, Oct 27, 2014 at 9:39 PM, Brian Faull <bfaull at cog-e.com> wrote: >> >> Hello, >> >> There may be plenty more experienced experts on DragonEgg (and hopefully >> they'll correct me if I'm wrong), but I figured I'd chime in with my brief >> experience to start. I have messed with this a bit, and DragonEgg has worked >> for my experiments. Your configuration has many things that are different >> than mine; however, I think you might simply have the cross-compilers >> crossed backward; I think you want to use your native gcc as >> compiler-driver; pass dragonegg.so to your native-gcc rather than >> tilera-gcc. I think you may simply need to do the following: >> >> 1- Build DragonEgg using your system compiler (or gcc 4.6.4 as recommended >> on dragonegg.llvm.org); when doing `make`, point explicitly at your *build* >> (x86_64) GCC of choice, and against your *target* (tilera) `llvm-config`. >> 2- use your x86_64 compiler-driver as front-end, which due to the magic of >> DragonEgg and llvm-config will use your target LLVM backend. >> >> Or it could be really late and I'm not thinking straight. :) >> >> More detail: >> I had to set a few non-obvious (to me) things in the build and use >> process, so I'll reflect them here for you and/or posterity. You will need >> all three components though: LLVM backend for your architecture (tilera) >> I'd suggest a few things to try, in order for you to find a configuration >> that works for you: >> >> * Sounds like you're on x86_64 / AMD64. I'd suggest to start with >> building the simplest configuration: using your system compiler to build >> everything for your system native architecture, and this will be the easiest >> configuration to debug. >> >> * According to the dragonegg.llvm.org web site, DragonEgg works best with >> GCC 4.6. You may wish to try that (I recommend looking at >> http://gcc.gnu.org/gcc-4.6/ for GCC 4.6.4, which is the latest release of >> that version). I don't know exactly why this version is said to work best; >> perhaps the DragonEgg site is simply stale. I bootstrapped a clean, native >> version of 4.6.4 without much headache. >> >> * Since I wanted to get DragonEgg built to work with GCC4.6.4, I built >> DragonEgg with GCC4.6.4. IIRC, the DragonEgg makefile wants you to specify >> the compiler as GCC=... rather than CC=... but it looks like it should eat >> both. Also, I read somewhere that LLVM3.3's llvm-config had some behavior >> that argues with DragonEgg. Contrary to best practice "build outside the >> source tree" so as to prevent polluting of the source tree, I saw a >> recommendation to build *within* the source tree, so I rolled back and built >> LLVM3.3 *in the source tree* (GASP!) for native (x86_64). In sum, to build >> DragonEgg I used something like >> GCC=/path/to/gcc464/bin/gcc >> LLVM_CONFIG=/path/to/llvm-3.3.src-x86_64/prefix/bin/llvm-config make >> >> * Then to use this shiny new .so, I started by going only up to the point >> of emitting LLVM IR so as not to confuse the situation with further >> architecture-specific compilation/assembly: >> /path/to/gcc464/bin/gcc -fplugin=/path/to/dragonegg.so >> -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c >> I also chose to specify the full path of dragonegg.so, so I didn't have to >> be concerned with library paths. >> >> Then you should be able to manually use your backend (llvm33/bin/llc, >> assembler, etc.) to generate an architecture-specific object. Once you've >> got all those components, you should be able to get everything integrated >> with just one gcc compiler-driver invocation. >> >> HTH, >> Brian >> >> >> >> >> On Oct 27, 2014, at 11:53 PM, Ajay Panyala <ajay.panyala at gmail.com> wrote: >> >> I am using a gcc (v 4.8.2) cross compiler for the tilera architecture. >> There is an LLVM (v 3.3) cross compiler available for tilera >> (http://tilera.github.io/llvm), >> but the frontend only has partial support for certain tilera intrinsics >> and no OpenMP support. >> >> Hence, I have decided to use DragonEgg (v 3.3) to resolve this. I was able >> to build >> DragonEgg, but when I pass the command line argument -fplugin=dragonegg.so >> when compiling with the tilera-gcc I get the error >> >> cannot load dragonegg.so: wrong ELF class: ELFCLASS64 >> >> i.e. the tilera-gcc does not accept the x86 shared library object >> dragonegg.so >> >> The dragonegg sources were built using the x86 GCC, but the plugin >> was built to load into the tilera gcc. >> >> Could someone please point out what I am missing here. >> >> Thanks >> Ajay >> _______________________________________________ >> 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 >-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
No. The gcc cross compiler being used (tilera-gcc) is indeed 64-bit. Thanks On Tue, Oct 28, 2014 at 11:01 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote:> Looks like your gcc is 32-bit and you're trying to load 64-bit plugin. > > On Tue, Oct 28, 2014 at 8:27 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > > Hi Brian, > > > > Thanks for sharing your experience with dragonegg. > > I would like to use tilera-gcc as the compiler driver. native gcc would > not > > be able to > > handle things like tilera specific intrinsics in the source code. > > > > I built dragonegg using > > > > GCC=/path/to/tilera-gcc48/bin/tile-gcc > > LLVM_CONFIG=/path/to/tilera-llvm/bin/tilegx-llvm-config make > > > > and also tried only emitting the IR > > > > /path/to/tilera-gcc48/bin/tile-gcc -fplugin=/path/to/dragonegg.so > > -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c > > > > (and still get the error: cannot load plugin dragonegg.so: wrong ELF > class: > > ELFCLASS64 ) > > > > - Ajay > > > > On Mon, Oct 27, 2014 at 9:39 PM, Brian Faull <bfaull at cog-e.com> wrote: > >> > >> Hello, > >> > >> There may be plenty more experienced experts on DragonEgg (and hopefully > >> they'll correct me if I'm wrong), but I figured I'd chime in with my > brief > >> experience to start. I have messed with this a bit, and DragonEgg has > worked > >> for my experiments. Your configuration has many things that are > different > >> than mine; however, I think you might simply have the cross-compilers > >> crossed backward; I think you want to use your native gcc as > >> compiler-driver; pass dragonegg.so to your native-gcc rather than > >> tilera-gcc. I think you may simply need to do the following: > >> > >> 1- Build DragonEgg using your system compiler (or gcc 4.6.4 as > recommended > >> on dragonegg.llvm.org); when doing `make`, point explicitly at your > *build* > >> (x86_64) GCC of choice, and against your *target* (tilera) > `llvm-config`. > >> 2- use your x86_64 compiler-driver as front-end, which due to the magic > of > >> DragonEgg and llvm-config will use your target LLVM backend. > >> > >> Or it could be really late and I'm not thinking straight. :) > >> > >> More detail: > >> I had to set a few non-obvious (to me) things in the build and use > >> process, so I'll reflect them here for you and/or posterity. You will > need > >> all three components though: LLVM backend for your architecture (tilera) > >> I'd suggest a few things to try, in order for you to find a > configuration > >> that works for you: > >> > >> * Sounds like you're on x86_64 / AMD64. I'd suggest to start with > >> building the simplest configuration: using your system compiler to build > >> everything for your system native architecture, and this will be the > easiest > >> configuration to debug. > >> > >> * According to the dragonegg.llvm.org web site, DragonEgg works best > with > >> GCC 4.6. You may wish to try that (I recommend looking at > >> http://gcc.gnu.org/gcc-4.6/ for GCC 4.6.4, which is the latest release > of > >> that version). I don't know exactly why this version is said to work > best; > >> perhaps the DragonEgg site is simply stale. I bootstrapped a clean, > native > >> version of 4.6.4 without much headache. > >> > >> * Since I wanted to get DragonEgg built to work with GCC4.6.4, I built > >> DragonEgg with GCC4.6.4. IIRC, the DragonEgg makefile wants you to > specify > >> the compiler as GCC=... rather than CC=... but it looks like it should > eat > >> both. Also, I read somewhere that LLVM3.3's llvm-config had some > behavior > >> that argues with DragonEgg. Contrary to best practice "build outside > the > >> source tree" so as to prevent polluting of the source tree, I saw a > >> recommendation to build *within* the source tree, so I rolled back and > built > >> LLVM3.3 *in the source tree* (GASP!) for native (x86_64). In sum, to > build > >> DragonEgg I used something like > >> GCC=/path/to/gcc464/bin/gcc > >> LLVM_CONFIG=/path/to/llvm-3.3.src-x86_64/prefix/bin/llvm-config make > >> > >> * Then to use this shiny new .so, I started by going only up to the > point > >> of emitting LLVM IR so as not to confuse the situation with further > >> architecture-specific compilation/assembly: > >> /path/to/gcc464/bin/gcc -fplugin=/path/to/dragonegg.so > >> -fplugin-arg-dragonegg-emit-ir -S -o hello.ll hello.c > >> I also chose to specify the full path of dragonegg.so, so I didn't have > to > >> be concerned with library paths. > >> > >> Then you should be able to manually use your backend (llvm33/bin/llc, > >> assembler, etc.) to generate an architecture-specific object. Once > you've > >> got all those components, you should be able to get everything > integrated > >> with just one gcc compiler-driver invocation. > >> > >> HTH, > >> Brian > >> > >> > >> > >> > >> On Oct 27, 2014, at 11:53 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > >> > >> I am using a gcc (v 4.8.2) cross compiler for the tilera architecture. > >> There is an LLVM (v 3.3) cross compiler available for tilera > >> (http://tilera.github.io/llvm), > >> but the frontend only has partial support for certain tilera intrinsics > >> and no OpenMP support. > >> > >> Hence, I have decided to use DragonEgg (v 3.3) to resolve this. I was > able > >> to build > >> DragonEgg, but when I pass the command line argument > -fplugin=dragonegg.so > >> when compiling with the tilera-gcc I get the error > >> > >> cannot load dragonegg.so: wrong ELF class: ELFCLASS64 > >> > >> i.e. the tilera-gcc does not accept the x86 shared library object > >> dragonegg.so > >> > >> The dragonegg sources were built using the x86 GCC, but the plugin > >> was built to load into the tilera gcc. > >> > >> Could someone please point out what I am missing here. > >> > >> Thanks > >> Ajay > >> _______________________________________________ > >> 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 > > > > > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141028/b28d595a/attachment.html>