DragonEgg3.3 support for gcc cross compilers

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.



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. :slight_smile:

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.


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

Looks like your gcc is 32-bit and you're trying to load 64-bit plugin.

No. The gcc cross compiler being used (tilera-gcc) is indeed 64-bit.


What does "file /path/to/tilera-gcc48/bin/tile-gcc" and "file
/path/to/dragonegg.so" report?

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.


Hi again Ajay,

I think my knowledge of DragonEgg is now exhausted. :slight_smile: 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?


Hi Brian,

Yes, the 64-bit build of the tilera tools should do it (file tile-gcc shows it to be a 32-bit executable).
I did not setup the tilera toolchain on this machine, but it looks like tile-gcc was configured as 32-bit by default.
The OS is a 64-bit RHEL 5. I will try the native compiler and target and also try build the
64-bit tilera gcc and see how it goes. Thanks a lot!

  • Ajay