[LLVMdev] DragonEgg3.3 support for gcc cross compilers (original) (raw)

Anton Korobeynikov anton at korobeynikov.info
Tue Oct 28 11:13:49 PDT 2014

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 > LLVMCONFIG=/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 >> (x8664) GCC of choice, and against your target (tilera) >> llvm-config. >> 2- use your x8664 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 x8664 / 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 (x8664). In sum, to >> build >> DragonEgg I used something like >> GCC=/path/to/gcc464/bin/gcc >> LLVMCONFIG=/path/to/llvm-3.3.src-x8664/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

More information about the llvm-dev mailing list