Rakesh Dhiman wrote:
Hi all,
I am trying to port kaffe-1.1.7 on bsp15 running customized linux 2.6.
The following are things which i have done:
Hi Rakesh,
1) Added entries to kaffe-1.1.7/config/config.alias as
bsp15*) Khost_cpu=bsp15 ;; inside the case "$Khost_cpu"
2) Added corresponding entries to all config.sub's
thanks for doing that, Rakesh. Could you add the patch for config.sub to
http://savannah.gnu.org/patch/?group=config , please ?
3) Created folders kaffe-1.1.7/config/bsp15 and
kaffe-1.1.7/config/bsp15/linux
4) Added files
- kaffe-1.1.7/config/bsp15/ atomic.h
- kaffe-1.1.7/config/bsp15/ common.h
- kaffe-1.1.7/config/bsp15/ threads.h
- kaffe-1.1.7/ config/bsp15/sysdepCallMethod.h
- kaffe-1.1.7/ config/bsp15/linux/config.frag
- kaffe-1.1.7/ config/bsp15/linux/md.c
- kaffe-1.1.7/ config/bsp15/linux/md.h
Cool.
The files are pasted below for reference. I have written my own
primitive sysdepCallMethod in C (Since i do not have support as far as
documentation to bsp15 architecture is concerned), which is running
fine as I have checked it thoroughly. I have not changed anything else
in the kaffe's code/config structure.
Nice.
5) I have configured the kaffe with follwing configuration script:
./configure --host=bsp15-linux --disable-gtk-peer
--without-alsa --without-esd --disable-direct-threading
--with-staticlib --with-engine=intrp
6) Cross compiled (make) with my bsp15 based tool chain (by setting
CC, AR, NM and CXX).
Sounds good. I've looked if I could find a publicly available
cross.compiler toolchain for the bsp15, but couldn't find one.
7) Installed.
My problem:
1) It runs and loads classes upto (when run using -v option) Loading
java/lang/IllegalThreadStateException.class and then stucks there
without printing anything and without creating any exception (
dump.txt is attached).
when i trace it with printf's, then it reveals that the system goes from
main to JNI_CreateJavaVM ( kaffe-1.1.7/kaffe/kaffevm/jni/jni-base.c)
to initialiseKaffe and returns safe from initialiseKaffe. After
returning initialiseKaffe, it never goes past
reftable = (jnirefs *)gc_malloc(sizeof(jnirefs) + sizeof(jref) *
DEFAULT_JNIREFS_NUMBER,
KGC_ALLOC_STATIC_THREADDATA); (inside kaffe-1
.1.7/kaffe/kaffevm/jni/jni-base.c just after returning from
initialiseKaffe )
You don't have to use printfs for debugging, if you can run gdb on your
target. See FAQ.debugging for details.
If Kaffe ends up being stuck in the gc, then you should inspect the
build logs (make clean && make >& build.log) for compiler warnings in
the gc module. You can also use
kaffe -vmdebug LIST to get a list of internal debugging options, and run
kaffe with kaffe -vmdebug ALL in the worst case, to get as much
debugging logs as possible.
I suspect something is wrong with my architecture/platform dependent
settings, such as SP_OFFSET etc (My bsp15/linux system doesn't run
kaffe-1.1.7/developers/sp_offset.c) to confirm it.
SP_OFFSET should not really matter for pthreads, afaict, and pthreads
are the default threading mechanism.
What may be the wrong? I am pasting my arch/platform dependent files
below. Output file (dump.txt) is attached.
Illegal read access to 0x80000000 from user PC 0x242adc; psw=0xa00f0
TID= 575 (kaffe-bin); ASID= 81
TLBS:
Could you get a backtrace in gdb? Or post the output of -vmdebug ALL,
alternatively.
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
