[kaffe] Porting kaffe-1.1.7 to bsp15/linux2.6

[Dalibor Topic]

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