shark improperly linked against llvm 2.4 (and first steps on ARM)

[Xerxes Rånby]

Hi Robert!

It is fun to see you taking on the task of getting shark to run on ARM. 
My shark adventures have only been able to run java -version and then 
crash so im thrilled to see that you have gotten your shark jvm past 
that part!
I have also got a beagleboard and are trying to get shark running on it.

Robert Schuster skrev:
> Hi,
> I was hunting down a problem where I could not get shark to run on ARM
> with llvm 2.4.
>   
How did you build your llvm 2.4? I have been trying to build llvm 2.4 
using the debian eperimental sourcetree for armel and my builds of llvm 
stops with the error undefined reference to `__register_frame' during 
compile of TargetSelect.cpp. Since i dont know how ARM EABI 
registerframes are supposed to look (if the even exists) i have sort of 
removed all references to __register_frame in my llvm sourcetree and 
hoped for the best with the thinking they are only used for debugging.

Im doing native compiles yet i suspect you are crosscompiling as you 
usually do, please clarify if you are crosscompiling llvm2.4 for arm and 
hints how to do so would be much appreciated. :)
> It turned out that the TargetMachineRegistry did not contain an entry
> for my machine at runtime. This is caused by not linking
> LLVMArmCodeGen.o into the final executable and that I is caused by
> IcedTea's configure script using 'engine' as the sole component when
> retrieving LLVM_LIBS.
>
> This is what it looks for 'engine' on my machine:
>
> rob at linkist:/$ llvm-config --libs engine
> /home/rob/oe/beagle/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib/LLVMInterpreter.o 
>
> /home/rob/oe/beagle/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib/LLVMExecutionEngine.o 
>
> /home/rob/oe/beagle/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib/LLVMJIT.o 
>
> -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa
> -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport -lLLVMSystem
>
> This is what it looks for 'nativecodegen' on my machine:
>
> rob at linkist:/$ llvm-config --libs nativecodegen
> /home/rob/oe/beagle/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib/LLVMARMCodeGen.o 
>
> -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils
> -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMSupport 
> -lLLVMSystem
>
>   
Would you ming creating a small patch to change  engine -> nativecodegen 
and send the patch to the list for inclusion with icedtea?
It would be great in my humble opinion.
> I am now using 'engine nativecodegen' as the requested components and
> this works fine. I retrieved those components by looking at what is
> needed to link llvm's lli program which runs fine.
>
> The reason for why linking in that module is neccessary is because those
> .o files contain static elements which register themselves to the
> TargetMachineRegistry when the elements are initialized.
> See include/llvm/Target/TargetMachineRegistry.h (search RegisterTarget)
> for details.
>
> A quick comparison with the llvm-config that Debian provides (2.2)
> reveals that 'nativecodegen' is not available with that version. So you
> probably need to declare a minimum supported llvm version. In case
> 'nativecodegen' should be used that would be 2.4.
>
> For ARM llvm and/or shark seems not to be 100% up to par ....
>
> root at beagleboard:~# java -version
> java version "1.6.0_0"
> IcedTea6 1.4 Runtime Environment (build 1.6.0_0-b14)
> OpenJDK Shark VM (build 14.0-b08, mixed mode)
> java:
> /home/rob/oe/beagle/tmp/work/armv7a-angstrom-linux-gnueabi/llvm-2.4-r0/llvm-2.4/include/llvm/CodeGen/MachineOperand.h:251: 
>
> int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() &&
> "Wrong MachineOperand accessor"' failed.
> Aborted
>
> ... but some simple apps already work:
>
> root at beagleboard:~# java HelloWorld
> Hello World!
>   
Cool! i have only been able to see java -version run :)
> java:
> /home/rob/oe/beagle/tmp/work/armv7a-angstrom-linux-gnueabi/llvm-2.4-r0/llvm-2.4/include/llvm/CodeGen/MachineOperand.h:251: 
>
> int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() &&
> "Wrong MachineOperand accessor"' failed.
> Aborted
>
> Do you think that assertion is a shark or an llvm issue?
>
>   
I think that is a llvm issue as most stuff in llvm:: namespace are.
> Regards
> Robert
>   

Hope to meet you on FOSDEM09!

Cheers and have a great day!
Xerxes