(original) (raw)

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@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@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@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@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@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@cs.uiuc.edu http://llvm.cs.uiuc.edu
\>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
\>> >>
\>> >>
\>> >
\>> >
\>> > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\>> > LLVM Developers mailing list
\>> > LLVMdev@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