[LLVMdev] DragonEgg3.3 support for gcc cross compilers
Brian Faull
bfaull at cog-e.com
Tue Oct 28 11:19:27 PDT 2014
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
More information about the llvm-dev
mailing list