[LLVMdev] DragonEgg3.3 support for gcc cross compilers

Tue Oct 28 11:01:00 PDT 2014

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