Re: [kaffe] cross-compile error
Dalibor Topic wrote: Dalibor Topic wrote: Robert Schuster wrote: Hi, Robert Schuster schrieb: I now found a cacheflush implementation in libffi. I adjust this for kaffe and report back. I took what was said here[0] as a base for an OABI- EABI-compliant implementation of the cache flushing. It compiles nicely (I can only test the EABI-variant here). Unfortunately it does not work at runtime. That means I get the same assertion failure as before: kaffe-bin: exception.c:100: vmExcept_setJNIFrame: Assertion `fp != (JNIFrameAddress)0' Now I dont know whether those two things are related. The only thing I know for sure is that I use the same cacheflush implementation for cacao and there it does its job (and fixes a real bug). Help! :) Thanks a lot for the patch, I can reproduce the build failure now, and I've fixed the build for the interpreter engine on arm linux (3 regression tests fail, which I think has more to do with fdlibm/classpath, than Kaffe, as there is a patch or two for arm issues in the classpath bug tracker). I'll look into fixing the build on arm-linux with the jit engines next using your patch. I've got aurelien's ARM Debian OABI image running, and I hope I can get one with EABI running, too. Ok, I've committed a fix for the build problem. Unfortunately, your patch still failed to compile on OABI, so I decided to use gcc's cache flushing code instead. On to the next problem: currently the jit regression test fails at a floating point test. Fixed per just committed patch. This lets the jit regression test pass, and lets Kaffe run the real regression tests. 26 fails on armel OABI linux with the jit engine. 0 with the interpreter engine. The interpreter engine on EABI looks like it will also have 0 regressions. I haven't tried the jit on EABI yet. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic schrieb: Dalibor Topic wrote: Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. Up to 4 failures on OABI with the patch at http://www.kaffe.org/~robilad/classpath-double-bits.diff . As far as I can see, Kaffe's floating point implementation is pretty bogus regarding VM spec compliance, and duplicates code all over the place. I'll try to fix it up a bit over the next couple of days. It's either a bug in ecj, or gcj, that caused the test cases to be miscompiled, and not a bug in Kaffe, which seems to be the only free VM that works as it should with class files on arm-oabi. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic wrote: Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. Up to 4 failures on OABI with the patch at http://www.kaffe.org/~robilad/classpath-double-bits.diff . As far as I can see, Kaffe's floating point implementation is pretty bogus regarding VM spec compliance, and duplicates code all over the place. I'll try to fix it up a bit over the next couple of days. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)
On Fri, 2008-02-08 at 00:26 +0100, Dalibor Topic wrote: I've looked a bit closer at the 3 ARM OABI errors, in particular at the errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fef we get 0x7fef. The current GNU Classpath implementation of Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, whenever __ARMEL__ is defined. That makes the DoubleConst test fail for Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of time trying to get it right on his ARM systems, I didn't want to mess with the corresponding file in fdlibm. So I wrote another implementation of the function, using ieee754.h (part of glibc). Basically, it boils down to shifting the bits from the bitfields to the right places inside the jlong. Easy. Unfortunately, that didn't work on arm OABI debian sid either. It turned out that glibc has a bug in the iee754.h header file, that comes to bite one on arm OABI. Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch attached. Meanwhile, that still means that those 3 tests fail until glibc is fixed. So ... I'll send in a couple of patches to the classpath patches list to first rewrite the doubleToLongBits in Java (and the same for Float), removing it from the VM interface, and then, I'll send in a patch to add the ieee754.h way of dealing with fetching the bits to the current way. Does that sound useful? That sounds actually very good, if it works on all configurations. I can remember we had a lot of problems to get these functions right on an Arm system with VFP. For more problems see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800 - twisti ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Classpath's doubleToLongBits (was: Re: [kaffe] cross-compile error)
Dalibor Topic wrote: Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. I've looked a bit closer at the 3 ARM OABI errors, in particular at the errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fef we get 0x7fef. The current GNU Classpath implementation of Java_java_lang_VMDouble_doubleToLongBits ends up swapping the words, whenever __ARMEL__ is defined. That makes the DoubleConst test fail for Cacao, Kaffe, etc. Since twisti said on IRC that he had spent a lot of time trying to get it right on his ARM systems, I didn't want to mess with the corresponding file in fdlibm. So I wrote another implementation of the function, using ieee754.h (part of glibc). Basically, it boils down to shifting the bits from the bitfields to the right places inside the jlong. Easy. Unfortunately, that didn't work on arm OABI debian sid either. It turned out that glibc has a bug in the iee754.h header file, that comes to bite one on arm OABI. Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464594 with a patch attached. Meanwhile, that still means that those 3 tests fail until glibc is fixed. So ... I'll send in a couple of patches to the classpath patches list to first rewrite the doubleToLongBits in Java (and the same for Float), removing it from the VM interface, and then, I'll send in a patch to add the ieee754.h way of dealing with fetching the bits to the current way. Does that sound useful? cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Wow, you did it by yourself... Dalibor Topic wrote: Dalibor Topic wrote: Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. Yes, in general tackling interpreter version first is a good practice. And in case of arm, it is better next to tackle jit1 rather than jit3, since I still did not fix register allocation bug in jit3. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. I've looked a bit closer at the 3 ARM OABI errors, in particular at the errors in test/regression/DoubleConst.java . That test fails because we get the bitstreams of the doubles being tested when we call Double.doubleToLongbits with swapped words, i.e. instead of 0x7fef we get 0x7fef. Yes, I noticed this is the place why it goes wrong. And then, I just simply leave it. Thanks to investigate why this problem happens. Similar problem happens for m68k implementations, and my feeling is doulbe support are not thoroughly tested except for ia32 arch :- Finally, I purchase ARM-9 based machines (mainly to debug NetBSD ports of kaffe) and I will check again with real machine whether floating to double conversion does not really work or not. If I noticed some differences between real hardware and QEMU, we have to file bug for QEMU. Does that sound useful? Yes, of course. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic wrote: My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? 3 failures on OABI, 5 on EABI, btw. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic schrieb: Dalibor Topic wrote: Robert Schuster wrote: Hi. Dalibor Topic schrieb: On to the next problem: currently the jit regression test fails at a floating point test. The FAQ.arm says: From Kaffe's point of view, only 'FPA' is supported right now. Some effort has been started to use 'VFP', and I hope we can rewrite this section soon. For jit/jit3 engine, the support of 'FPA' is mandatory (the internal code generation emits FPA instruction) and if you don't have FPA (or FPA emulation by the operating system) only possibility is to use interpreter engine. I think that this may be the reason for the failing floating point test. Debian arm on QEMU uses fpa (hard), so that's not causing the problem (and libffi does not help, either). It turned out that float to int conversion of NaNs was broken in some way, so I ripped that code out of the arm jit engine. Using the soft float to int conversion, the regression test on the jit engine pass, up to a hang after generating VMThrowable.fillInStackTrace and the soft_fixup_trampoline returning a value. There is a warning related to soft_fixup_trampoline on arm (and it stretches all along the code use COMPARE_AND_EXCHANGE), so I'll try to see if using glib's atomic functions helps. It helps fix the specific warning, but I'd like to take a closer look at locks.c, that uses COMPARE_AND_EXCHANGE, too, post 1.1.9. It wasn't the cause of the problem, anyway. Looking a bit closer at this through gdb, it seems that we end up in an infinite loop inside the buildStackTrace function when counting the stack traces. So the next step would be to try to figure out what's wrong with the exception frame code for arm-linux. My wild guess is that __builtin_frame_address(0) on gcc 4.1+ rears its ugly head again... I've played a bit further with this, and now I've got a patch that changes the buildStackTrace function to stop counting frames when we start looping frames (happens on arm-linux-oabi). That fixes the jit test, and lets all but 27 regression tests pass in jit mode (gcc 4.2, libffi, etc.). I'll clean it up, and separate it from the bits that replace COMPARE_AND_EXCHANGE with glib, and commit it. The EABI jit test fails on returning float constant 0.0, as it gets 0x0001 back. Any ideas from EABI folks what may be causing that, and how to go about tracking it down? My plan would be to look at making the interpreter pass on arm-oabi and arm-eabi without failures, and then to move on to the jits. I'd also like to see if I can rip out all the atomic* code in Kaffe's config dirs by using glib's atomic functions instead, as that would be less low level code from libc to keep around as copies in Kaffe. Any volunteers for the arm-* interpreter failures? cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Hi. Dalibor Topic schrieb: On to the next problem: currently the jit regression test fails at a floating point test. The FAQ.arm says: From Kaffe's point of view, only 'FPA' is supported right now. Some effort has been started to use 'VFP', and I hope we can rewrite this section soon. For jit/jit3 engine, the support of 'FPA' is mandatory (the internal code generation emits FPA instruction) and if you don't have FPA (or FPA emulation by the operating system) only possibility is to use interpreter engine. I think that this may be the reason for the failing floating point test. Regards Robert signature.asc Description: OpenPGP digital signature ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Robert Schuster wrote: Hi. Dalibor Topic schrieb: On to the next problem: currently the jit regression test fails at a floating point test. The FAQ.arm says: From Kaffe's point of view, only 'FPA' is supported right now. Some effort has been started to use 'VFP', and I hope we can rewrite this section soon. For jit/jit3 engine, the support of 'FPA' is mandatory (the internal code generation emits FPA instruction) and if you don't have FPA (or FPA emulation by the operating system) only possibility is to use interpreter engine. I think that this may be the reason for the failing floating point test. Debian arm on QEMU uses fpa (hard), so that's not causing the problem (and libffi does not help, either). It turned out that float to int conversion of NaNs was broken in some way, so I ripped that code out of the arm jit engine. Using the soft float to int conversion, the regression test on the jit engine pass, up to a hang after generating VMThrowable.fillInStackTrace and the soft_fixup_trampoline returning a value. There is a warning related to soft_fixup_trampoline on arm (and it stretches all along the code use COMPARE_AND_EXCHANGE), so I'll try to see if using glib's atomic functions helps. cheers. dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic wrote: Robert Schuster wrote: Hi. Dalibor Topic schrieb: On to the next problem: currently the jit regression test fails at a floating point test. The FAQ.arm says: From Kaffe's point of view, only 'FPA' is supported right now. Some effort has been started to use 'VFP', and I hope we can rewrite this section soon. For jit/jit3 engine, the support of 'FPA' is mandatory (the internal code generation emits FPA instruction) and if you don't have FPA (or FPA emulation by the operating system) only possibility is to use interpreter engine. I think that this may be the reason for the failing floating point test. Debian arm on QEMU uses fpa (hard), so that's not causing the problem (and libffi does not help, either). It turned out that float to int conversion of NaNs was broken in some way, so I ripped that code out of the arm jit engine. Using the soft float to int conversion, the regression test on the jit engine pass, up to a hang after generating VMThrowable.fillInStackTrace and the soft_fixup_trampoline returning a value. There is a warning related to soft_fixup_trampoline on arm (and it stretches all along the code use COMPARE_AND_EXCHANGE), so I'll try to see if using glib's atomic functions helps. It helps fix the specific warning, but I'd like to take a closer look at locks.c, that uses COMPARE_AND_EXCHANGE, too, post 1.1.9. It wasn't the cause of the problem, anyway. Looking a bit closer at this through gdb, it seems that we end up in an infinite loop inside the buildStackTrace function when counting the stack traces. So the next step would be to try to figure out what's wrong with the exception frame code for arm-linux. My wild guess is that __builtin_frame_address(0) on gcc 4.1+ rears its ugly head again... cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Dalibor Topic wrote: Robert Schuster wrote: Hi, Robert Schuster schrieb: I now found a cacheflush implementation in libffi. I adjust this for kaffe and report back. I took what was said here[0] as a base for an OABI- EABI-compliant implementation of the cache flushing. It compiles nicely (I can only test the EABI-variant here). Unfortunately it does not work at runtime. That means I get the same assertion failure as before: kaffe-bin: exception.c:100: vmExcept_setJNIFrame: Assertion `fp != (JNIFrameAddress)0' Now I dont know whether those two things are related. The only thing I know for sure is that I use the same cacheflush implementation for cacao and there it does its job (and fixes a real bug). Help! :) Thanks a lot for the patch, I can reproduce the build failure now, and I've fixed the build for the interpreter engine on arm linux (3 regression tests fail, which I think has more to do with fdlibm/classpath, than Kaffe, as there is a patch or two for arm issues in the classpath bug tracker). I'll look into fixing the build on arm-linux with the jit engines next using your patch. I've got aurelien's ARM Debian OABI image running, and I hope I can get one with EABI running, too. Ok, I've committed a fix for the build problem. Unfortunately, your patch still failed to compile on OABI, so I decided to use gcc's cache flushing code instead. On to the next problem: currently the jit regression test fails at a floating point test. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Robert Schuster wrote: Hi, Robert Schuster schrieb: I now found a cacheflush implementation in libffi. I adjust this for kaffe and report back. I took what was said here[0] as a base for an OABI- EABI-compliant implementation of the cache flushing. It compiles nicely (I can only test the EABI-variant here). Unfortunately it does not work at runtime. That means I get the same assertion failure as before: kaffe-bin: exception.c:100: vmExcept_setJNIFrame: Assertion `fp != (JNIFrameAddress)0' Now I dont know whether those two things are related. The only thing I know for sure is that I use the same cacheflush implementation for cacao and there it does its job (and fixes a real bug). Help! :) Thanks a lot for the patch, I can reproduce the build failure now, and I've fixed the build for the interpreter engine on arm linux (3 regression tests fail, which I think has more to do with fdlibm/classpath, than Kaffe, as there is a patch or two for arm issues in the classpath bug tracker). I'll look into fixing the build on arm-linux with the jit engines next using your patch. I've got aurelien's ARM Debian OABI image running, and I hope I can get one with EABI running, too. cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Hi,
Robert Schuster schrieb:
I now found a cacheflush implementation in libffi. I adjust this for
kaffe and report back.
I took what was said here[0] as a base for an OABI- EABI-compliant
implementation of the cache flushing.
It compiles nicely (I can only test the EABI-variant here).
Unfortunately it does not work at runtime. That means I get the same
assertion failure as before:
kaffe-bin: exception.c:100: vmExcept_setJNIFrame: Assertion `fp !=
(JNIFrameAddress)0'
Now I dont know whether those two things are related. The only thing I
know for sure is that I use the same cacheflush implementation for cacao
and there it does its job (and fixes a real bug).
Help! :)
Regards
Robert
[0] - http://gcc.gnu.org/ml/java-patches/2007-q3/msg00112.html
Regards
Robert
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Index: kaffe-cvs/config/arm/linux/md.c
===
--- kaffe-cvs.orig/config/arm/linux/md.c 2008-01-21 00:04:12.0 +0100
+++ kaffe-cvs/config/arm/linux/md.c 2008-01-21 00:50:30.0 +0100
@@ -33,11 +33,25 @@
* for 2.6) should be okay.
*/
void flush_dcache(void *start, void *end) {
- __asm __volatile (mov r0, %0\n
+#if defined(__ARM_EABI__)
+ __asm __volatile (
+mov r0, %0\n
mov r1, %1\n
mov r2, #0\n
- swi __sys1(__ARM_NR_cacheflush) \n
+mov r7, #0x0f\n
+add r7, r7, #0x02\n
+ swi 0x0\n
+ : /* no return value */
+ : r ((long)start), r ((long)end)
+ : r0,r1,r2,r7);
+#else /* OABI */
+ __asm __volatile (
+mov r0, %0\n
+ mov r1, %1\n
+ mov r2, #0\n
+ swi sys_cacheflush\n
: /* no return value */
: r ((long)start), r ((long)end)
: r0,r1,r2);
+#endif
}
signature.asc
Description: OpenPGP digital signature
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Hi, talking to Dalibor on IRC he said there are some interesting compiler warnings in my build and he is going to look at them. Robert Schuster schrieb: kaffe-bin: exception.c:100: vmExcept_setJNIFrame: Assertion `fp != (JNIFrameAddress)0' Perhaps a backtrace for this is of interest: #0 0x40042a38 in vmExcept_setJNIFrame () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #1 0x4004f1bc in KaffeVM_safeCallMethodA () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #2 0x4003a0ec in processClass () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #3 0x400368dc in initBaseClasses () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #4 0x40036e9c in initialiseKaffe () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #5 0x40055fc8 in JNI_CreateJavaVM () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #6 0x9c30 in main () Regards Robert signature.asc Description: OpenPGP digital signature ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Hi, its me again. Robert Schuster schrieb: #0 0x40042a38 in vmExcept_setJNIFrame () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #1 0x4004f1bc in KaffeVM_safeCallMethodA () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #2 0x4003a0ec in processClass () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #3 0x400368dc in initBaseClasses () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #4 0x40036e9c in initialiseKaffe () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #5 0x40055fc8 in JNI_CreateJavaVM () from /usr/lib/kaffe/jre/lib/arm/libkaffe-1.1.9-pre.so #6 0x9c30 in main () Forget this. It is not the location where the assertion failed. :( Regards Robert signature.asc Description: OpenPGP digital signature ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Hi Robert, I just tried to cross-compile kaffe for ARM (I read the FAQ :) ). The It's good to hear from someone that FAQ.cross-compiling is useful ;-) target (and toolchain) is GNU EABI which is not officially supported in kaffe. So perhaps my compile error is just because of that - I get this: md.c: In function 'flush_dcache': md.c:39: error: expected ':' or ')' before '__sys1' md.c:35: warning: unused parameter 'start' md.c:35: warning: unused parameter 'end' make[2]: *** [libkaffe_la-md.lo] Error 1 It should not be related to EABI. This is common for recent version of linux distribution for arm. You simply add #define KERNEL just before the include for unistd. Without having KERNEL defined, __sys1 is not defined, and you get this error. Kiyo ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross-compile error
Kiyo Inaba wrote: Hi Robert, I just tried to cross-compile kaffe for ARM (I read the FAQ :) ). The It's good to hear from someone that FAQ.cross-compiling is useful ;-) target (and toolchain) is GNU EABI which is not officially supported in kaffe. So perhaps my compile error is just because of that - I get this: md.c: In function 'flush_dcache': md.c:39: error: expected ':' or ')' before '__sys1' md.c:35: warning: unused parameter 'start' md.c:35: warning: unused parameter 'end' make[2]: *** [libkaffe_la-md.lo] Error 1 It should not be related to EABI. This is common for recent version of linux distribution for arm. You simply add #define KERNEL just before the include for unistd. Without having KERNEL defined, __sys1 is not defined, and you get this error. I'm curious, does cross compiling cacao work and result in a working binary? If it does, could you try using the flush dcache arm assembler implementation from cacao in Kaffe? cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] cross compile error
[EMAIL PROTECTED] wrote: Hi...all. I want to cross compile for arm architecture. But, When configuring, saw the error messages. [EMAIL PROTECTED] kaffe-1.1.4]# CC=arm-linux-gcc NM=arm-linux-nm AR=arm-linux-ar ./configure --host=arm-linux --build=i686-linux checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for arm-linux-strip... arm-linux-strip checking whether to enable maintainer-specific portions of Makefiles... no checking for arm-linux-gcc... arm-linux-gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See 'config.log' for more details. Hi, that looks odd. What does config.log say about arm-linux-gcc? cheers, dalibor topic ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
