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>
Anton Korobeynikov
2014-Oct-28 18:13 UTC
[LLVMdev] DragonEgg3.3 support for gcc cross compilers
What does "file /path/to/tilera-gcc48/bin/tile-gcc" and "file /path/to/dragonegg.so" report? On Tue, Oct 28, 2014 at 9:11 PM, Ajay Panyala <ajay.panyala at gmail.com> wrote:> 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 > >-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Sorry. You were right. Its a 32-bit executable. This machine was setup by someone else and I assumed everything was 64-bit, but clearly its not. Thanks Ajay On Tue, Oct 28, 2014 at 11:13 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote:> What does "file /path/to/tilera-gcc48/bin/tile-gcc" and "file > /path/to/dragonegg.so" report? > > On Tue, Oct 28, 2014 at 9:11 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > > 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 > > > > > > > > -- > 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/e6c0627e/attachment.html>
Hi again Ajay, I think my knowledge of DragonEgg is now exhausted. :) Still seems like this should be possible; here’s a few more questions and suggestions. Building on Anton says, 32-/64-bit could be the situation: * Are you on 32b Linux -- or what architecture are you on (e.g., what does `uname -a` give you? * Or, how is your tile-gcc configured (e.g., configure --build=? --host=? --target=tilera?). * If you are on an x86_64 system, you might be using, say, multilib and a 32-bit tile-gcc or something. E.g., what does `file tile-gcc` give you? I still don't think you want to build DragonEgg with tile-gcc. Try building dragonegg.so using your system gcc, then using `tile-gcc -fplugin=...` As another hack, it might be possible to put your sources through `tile-gcc` just through the preprocessor (e.g., `tile-gcc -E -o ...`) but that's a bit of a kludge and depends on what the nature of the target-specific items in your sources are. I think you might want to step back and try to get DragonEgg working on a native compiler with native target. Would you try my "first bullet" in my original response -- configure native gcc, native llvm, build dragonegg.so, then use same to build a helloworld? Brian> On Oct 28, 2014, at 2:13 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > What does "file /path/to/tilera-gcc48/bin/tile-gcc" and "file > /path/to/dragonegg.so" report? > > On Tue, Oct 28, 2014 at 9:11 PM, Ajay Panyala <ajay.panyala at gmail.com> wrote: >> 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 >> >> > > > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University