I made some early experiments --- namely a llvm program that
printf'd "hello world" -- that seemed to indicate that a bitcode file
I generate on linux would work on my solaris box. Well, they're
actually the same machine, an amd opteron sun box with a linux vm
running. My generating program doesn't run on solaris, but I was
hoping to generate bitcode for it from linux. lli crashes pretty
quick (although the same use on linux has been debugged pretty well,
and it's a pretty simple program!). llvmc -clang complains quite a
bit about invalid directives (sorry, couldn't get on the machine
before my commute to work, so this is from memory only).
I read something quite some time ago that perhaps the bitcode wasn't
portable if the machines had different pointer sizes. Solaris is
64bit (almost exclusively). I tried generating from both 32 and 64
bit linux VMs, but perhaps I just didn't configure it properly to
generate 64-bit code?
I thought it was supposed to be portable? Am I wrong? llvm-dis works
on it fine. Perhaps a llvm-dis -> llvm-as cycle would do the trick?
I can post the (small) bitcode file and the errors tonight, if that helps.
Any help is really appreciated. Thanks in advance!
I made some early experiments --- namely a llvm program that
printf'd "hello world" -- that seemed to indicate that a bitcode file
I generate on linux would work on my solaris box. Well, they're
actually the same machine, an amd opteron sun box with a linux vm
running. My generating program doesn't run on solaris, but I was
hoping to generate bitcode for it from linux. lli crashes pretty
quick (although the same use on linux has been debugged pretty well,
and it's a pretty simple program!). llvmc -clang complains quite a
bit about invalid directives (sorry, couldn't get on the machine
before my commute to work, so this is from memory only).
I read something quite some time ago that perhaps the bitcode wasn't
portable if the machines had different pointer sizes. Solaris is
64bit (almost exclusively). I tried generating from both 32 and 64
bit linux VMs, but perhaps I just didn't configure it properly to
generate 64-bit code?
I thought it was supposed to be portable? Am I wrong? llvm-dis works
on it fine. Perhaps a llvm-dis -> llvm-as cycle would do the trick?
I can post the (small) bitcode file and the errors tonight, if that helps.
Any help is really appreciated. Thanks in advance!
It is probably an ABI issue, your bitcode specifies the Linux ABI, and
trying to use that on Solaris won't work.
Try deleting the triple from the module, or editing it to be the proper
one for Solaris.
Also you'll probably need to use the Solaris headers when
cross-compiling your bitcode, but that shouldn't matter for just calling
printf.
To answer my own question. The problem is that Solaris ships with
very old tools, and llvmc was generating assembler that worked with a
fresh (gcc-4.5) compile & install. I had them handy, just further
down the path. Hopefully anyone with the same problem can find this
in the archive.
I think llvm isn't ported to Solaris i386/x86_64 yet. Particularly, clang there prints the same data layout string as on linux assuming ABI is the same when it isn't. So using your approach certain calls to the externally compiled libraries will cause failures. Some simpler examples may work fine.
I think llvm isn't ported to Solaris i386/x86_64 yet. Particularly, clang
there prints the same data layout string as on linux assuming ABI is the
same when it isn't. So using your approach certain calls to the externally
compiled libraries will cause failures. Some simpler examples may work fine.
Well, then I'm royally screwed.
What would I have to add to make it work, if only for a very limited
subset of cases?
Fixing the data layout is simple:
1. Read the LLVM Laguage Reference to learn how to format the data
layout string.
2. Look up what's the actual data layout for your platform.
3. Implement the string in lib/Target/X86/X86TargetMachine.cpp
The last step may require implementing some handling for the triplet of
your platform, but if you are on a hurry and don't plan to contribute
your changes to LLVM nor to generate code for other platforms an #ifdef
will do.