sablevm-developer Mailing List for SableVM (Page 53)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
| 2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
| 2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Archie C. <ar...@de...> - 2003-01-01 03:30:04
|
FYI,
There is a bug in Classpath's UTF8 encoding class...
http://sourceforge.net/tracker/index.php?func=detail&aid=660598&group_id=5523&atid=105523
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: Etienne M. G. <eti...@uq...> - 2002-12-19 06:42:21
|
Hi everyone. First, I'd like to thank everyone on the SableVM and SableCC lists for your patience coping with my sparse availability during my Ph.D. studies. I'd also like to more specifically thank the various SableVM developers that ported it to many platforms and helped identifying and fixing bugs. I have just posted the end result of all this work, my Ph.D. thesis, at: http://www.info.uqam.ca/~egagnon/gagnon-phd.pdf http://www.info.uqam.ca/~egagnon/gagnon-phd.ps.gz Within the next three weeks, I will take *real* holiday vacations. It has been a very long time since I had vacations with peace of mind (i.e. no thesis to write). Starting in the second half of January, I will become active on both the SableVM and SableCC projects. Already, many users/developers of both project have contributed new modules and patches. In particular, a student of mine has implemented grammar-specified CST->AST transformations in SableCC (as well as rewriting the front-end so that SableCC is self generating). I will start integrating these changes when I get back froma vacations. Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-18 19:59:12
|
Hello, Here it is as an unified diff. David On Wed, Dec 18, 2002 at 09:16:57AM -0500, Etienne M. Gagnon wrote: > David Paul BELANGER wrote: > >Etienne, > > > >I am sending the powerpc patch I have. The patch is against release > >1.0.5. Let me know the correct/prefered patch format, I am not=20 > >familiar with diff/patch. >=20 > The preferred patch format is "diff -u" (unified diffs). >=20 > Could you resend the patch in this format? >=20 > Thanks a lot for your work! >=20 > Etienne >=20 > > > >It was not heavily tested yet. I'm not sure if the libffi bug work > >around works 100%. Other parts should be correct. > > > > > >David > > > > > >--- > > > >David B=E9langer > >Graduate Student > >School of Computer Science > >McGill University > >Office: MC226 > > > >Web page: http://www.cs.mcgill.ca/~dbelan2/ > >Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt > > > > > > > >----------------------------------------------------------------------= -- > > > >Index: sablevm-1.0.5/src/libsablevm/native.c > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file:=20 > >/home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/native.c,= v > >retrieving revision 1.1.1.1 > >retrieving revision 1.3 > >diff -c -r1.1.1.1 -r1.3 > >*** sablevm-1.0.5/src/libsablevm/native.c 13 Dec 2002 01:52:11 -0000=20 > >1.1.1.1 > >--- sablevm-1.0.5/src/libsablevm/native.c 14 Dec 2002 02:40:34 -0000=20 > >1.3 > >*************** > >*** 325,331 **** > >--- 325,335 ---- > > case 'B': > > { > > method->data.native_method->arg_types[i] =3D SVM_TYPE_BYTE; > >+ #ifdef LIBFFIBUG > >+ method->data.native_method->args[i] =3D &ffi_type_uint; > >+ #else > > method->data.native_method->args[i] =3D &ffi_type_sint8; > >+ #endif > > i++; > > } > > break; > >*************** > >*** 333,339 **** > >--- 337,347 ---- > > case 'C': > > { > > method->data.native_method->arg_types[i] =3D SVM_TYPE_CHAR; > >+ #ifdef LIBFFIBUG > >+ method->data.native_method->args[i] =3D &ffi_type_uint; > >+ #else > > method->data.native_method->args[i] =3D &ffi_type_uint16; > >+ #endif > > i++; > > } > > break; > >*************** > >*** 357,363 **** > >--- 365,375 ---- > > case 'S': > > { > > method->data.native_method->arg_types[i] =3D SVM_TYPE_SHORT; > >+ #ifdef LIBFFIBUG > >+ method->data.native_method->args[i] =3D &ffi_type_uint; > >+ #else > > method->data.native_method->args[i] =3D &ffi_type_sint16; > >+ #endif > > i++; > > } > > break; > >*************** > >*** 365,371 **** > >--- 377,387 ---- > > case 'Z': > > { > > method->data.native_method->arg_types[i] =3D SVM_TYPE_BOOLEAN; > >+ #ifdef LIBFFIBUG > >+ method->data.native_method->args[i] =3D &ffi_type_uint; > >+ #else > > method->data.native_method->args[i] =3D &ffi_type_uint8; > >+ #endif > > i++; > > } > > break; > >*************** > >*** 904,910 **** > >--- 920,930 ---- > > case SVM_TYPE_BOOLEAN: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jboolean *) &result[0]) + 3); > >+ #else =20 > > params[0].jint =3D *((jboolean *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 912,918 **** > >--- 932,942 ---- > > case SVM_TYPE_BYTE: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jbyte *) &result[0]) + 3); > >+ #else > > params[0].jint =3D *((jbyte *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 920,926 **** > >--- 944,954 ---- > > case SVM_TYPE_SHORT: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jshort *) &result[0]) + 2); > >+ #else > > params[0].jint =3D *((jshort *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 928,934 **** > >--- 956,966 ---- > > case SVM_TYPE_CHAR: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jchar *) &result[0]) + 2); > >+ #else > > params[0].jint =3D *((jchar *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 1238,1247 **** > > } > > break; > > =20 > >! case SVM_TYPE_BOOLEAN: > > { > >! /* don't forget about little/big endian alignment */ > > params[0].jint =3D *((jboolean *) &result[0]); > > frame->stack_size++; > > } > > break; > >--- 1270,1284 ---- > > } > > break; > > =20 > >! case SVM_TYPE_BOOLEAN: =20 > > { > >!=20 > >! #ifdef LIBFFIBUG > >! params[0].jint =3D *(((jboolean *) &result[0]) + 3); > >! #else > > params[0].jint =3D *((jboolean *) &result[0]); > >+ #endif > >+=20 > > frame->stack_size++; > > } > > break; > >*************** > >*** 1249,1255 **** > >--- 1286,1296 ---- > > case SVM_TYPE_BYTE: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jbyte *) &result[0]) + 3); > >+ #else > > params[0].jint =3D *((jbyte *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 1257,1263 **** > >--- 1298,1308 ---- > > case SVM_TYPE_SHORT: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jshort *) &result[0]) + 2); > >+ #else > > params[0].jint =3D *((jshort *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >*************** > >*** 1265,1271 **** > >--- 1310,1320 ---- > > case SVM_TYPE_CHAR: > > { > > /* don't forget about little/big endian alignment */ > >+ #ifdef LIBFFIBUG > >+ params[0].jint =3D *(((jchar *) &result[0]) + 2); > >+ #else > > params[0].jint =3D *((jchar *) &result[0]); > >+ #endif > > frame->stack_size++; > > } > > break; > >Index: sablevm-1.0.5/src/libsablevm/system.c > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file:=20 > >/home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/system.c,= v > >retrieving revision 1.1.1.1 > >diff -c -r1.1.1.1 system.c > >*** sablevm-1.0.5/src/libsablevm/system.c 13 Dec 2002 01:52:11 -0000=20 > >1.1.1.1 > >--- sablevm-1.0.5/src/libsablevm/system.c 18 Dec 2002 02:23:30 -0000 > >*************** > >*** 5,11 **** > > * modification of SableVM. * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ))=20 > >&& defined (__GNUC__)) > > =20 > > /* > > --------------------------------------------------------------------= -- > >--- 5,11 ---- > > * modification of SableVM. * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ) ||=20 > >defined (__powerpc__)) && defined (__GNUC__)) > > =20 > > /* > > --------------------------------------------------------------------= -- > >*************** > >*** 109,114 **** > >--- 109,144 ---- > > result =3D __sync_bool_compare_and_swap (pword, old_value, new_val= ue); > > =20 > > #endif > >+=20 > >+ #if (defined (__powerpc__)) > >+=20 > >+ int result; > >+=20 > >+ /* > >+ * Adapted from the glibc-linuxthreads, file pt-machine.h > >+ * > >+ */ > >+ __asm__ __volatile__ ( > >+ "0: lwarx %0,0,%1 ;" > >+ " xor. %0,%3,%0;" > >+ " bne 1f;" > >+ " stwcx. %2,0,%1;" > >+ " bne- 0b;" > >+ "1: " > >+ : "=3D&r"(result) > >+ : "r"(pword), "r"(new_value), "r"(old_value) > >+ : "cr0", "memory"); > >+ /* This version of __compare_and_swap is to be used when acquiring > >+ a lock, so we don't need to worry about whether other memory > >+ operations have completed, but we do need to be sure that any l= oads > >+ after this point really occur after we have acquired the lock. = */ > >+ __asm__ __volatile__ ("isync" : : : "memory"); > >+=20 > >+ /* flip the value of result */ > >+ result =3D !result; > >+=20 > >+ #endif > >+=20 > > =20 > > return result ? JNI_TRUE : JNI_FALSE; > > } > >Index: sablevm-1.0.5/src/libsablevm/system.h > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file:=20 > >/home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/system.h,= v > >retrieving revision 1.1.1.1 > >diff -c -r1.1.1.1 system.h > >*** sablevm-1.0.5/src/libsablevm/system.h 13 Dec 2002 01:52:11 -0000=20 > >1.1.1.1 > >--- sablevm-1.0.5/src/libsablevm/system.h 18 Dec 2002 02:30:27 -0000 > >*************** > >*** 48,54 **** > > =20 > > */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ))=20 > >&& defined (__GNUC__)) > > =20 > > /* "inline" is now an official keyword since the latest C standard=20 > > (1999). > > So, it is a reasonable assuption to expect a target compiler to > >--- 48,54 ---- > > =20 > > */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ) ||=20 > >defined (__powerpc__)) && defined (__GNUC__)) > > =20 > > /* "inline" is now an official keyword since the latest C standard=20 > > (1999). > > So, it is a reasonable assuption to expect a target compiler to > >*************** > >*** 100,107 **** > >--- 100,120 ---- > > #define SVM_ALIGNMENT_POWER 3 /* 2 ^^ SVM_ALIGNMENT_POWER =3D=3D=20 > > SVM_ALIGNMENT */ > > #define SVM_PAGE_SIZE 16384 > > =20 > >+ #elif defined (__powerpc__) > >+=20 > >+ typedef _svmt_u32 _svmt_word; > >+=20 > >+ #define SVM_WORD_SIZE 4 /* size in bytes */ > >+ #define SVM_WORD_BIT_COUNT 32 /* size in bits */ > >+=20 > >+ /* see comments at the head of this file */ > >+ #define SVM_ALIGNMENT 8 > >+ #define SVM_ALIGNMENT_POWER 3 /* 2 ^^ SVM_ALIGNMENT_POWER =3D=3D=20 > >SVM_ALIGNMENT */ > >+ #define SVM_PAGE_SIZE 4096 > >+=20 > > #endif > > =20 > >+=20 > > /* FFI specific types */ > > #define ffi_type_float32 ffi_type_float > > #define ffi_type_float64 ffi_type_double > >*************** > >*** 163,165 **** > >--- 176,179 ---- > > #endif > > =20 > > #endif /* not SVM_SYSTEM_H */ > >+=20 > >Index: sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file:=20 > >/home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/include/j= ni_system_specific.h,v > >retrieving revision 1.1.1.1 > >retrieving revision 1.2 > >diff -c -r1.1.1.1 -r1.2 > >*** sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h 13=20 > >Dec 2002 01:52:11 -0000 1.1.1.1 > >--- sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h 13=20 > >Dec 2002 19:58:44 -0000 1.2 > >*************** > >*** 15,21 **** > > =20 > > /* alpha and i386 are identical here */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ))=20 > >&& defined (__GNUC__)) > > =20 > > #define JNICALL > > #define JNIEXPORT > >--- 15,21 ---- > > =20 > > /* alpha and i386 are identical here */ > > =20 > >! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__= ) ||=20 > >defined (__powerpc__)) && defined (__GNUC__)) > > =20 > > #define JNICALL > > #define JNIEXPORT > >Index: sablevm-native-library-1.0.5/src/include/jni_system_specific.h > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file:=20 > >/home/david/cvsroot/sablevm_ppc/sablevm-native-library-1.0.5/src/inclu= de/jni_system_specific.h,v > >retrieving revision 1.1.1.1 > >retrieving revision 1.2 > >diff -c -r1.1.1.1 -r1.2 > >*** sablevm-native-library-1.0.5/src/include/jni_system_specific.h 13=20 > >Dec 2002 01:52:11 -0000 1.1.1.1 > >--- sablevm-native-library-1.0.5/src/include/jni_system_specific.h 13=20 > >Dec 2002 19:59:23 -0000 1.2 > >*************** > >*** 8,14 **** > > =20 > > /* system specific primitive types */ > > =20 > >! #if (defined (__i386__) && defined (__GNUC__)) > > =20 > > /* legend: > > u =3D unsigned intger, s =3D signed integer, f =3D float, d =3D = double > >--- 8,14 ---- > > =20 > > /* system specific primitive types */ > > =20 > >! #if ((defined (__i386__) || defined (__powerpc__)) && defined (__GNU= C__)) > > =20 > > /* legend: > > u =3D unsigned intger, s =3D signed integer, f =3D float, d =3D = double >=20 > --=20 > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-18 14:22:57
|
David Paul BELANGER wrote: > Etienne, >=20 > I am sending the powerpc patch I have. The patch is against release > 1.0.5. Let me know the correct/prefered patch format, I am not=20 > familiar with diff/patch. The preferred patch format is "diff -u" (unified diffs). Could you resend the patch in this format? Thanks a lot for your work! Etienne >=20 > It was not heavily tested yet. I'm not sure if the libffi bug work > around works 100%. Other parts should be correct. >=20 >=20 > David >=20 >=20 > --- >=20 > David B=E9langer > Graduate Student > School of Computer Science > McGill University > Office: MC226 >=20 > Web page: http://www.cs.mcgill.ca/~dbelan2/ > Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > Index: sablevm-1.0.5/src/libsablevm/native.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/= native.c,v > retrieving revision 1.1.1.1 > retrieving revision 1.3 > diff -c -r1.1.1.1 -r1.3 > *** sablevm-1.0.5/src/libsablevm/native.c 13 Dec 2002 01:52:11 -0000 1.= 1.1.1 > --- sablevm-1.0.5/src/libsablevm/native.c 14 Dec 2002 02:40:34 -0000 1.= 3 > *************** > *** 325,331 **** > --- 325,335 ---- > case 'B': > { > method->data.native_method->arg_types[i] =3D SVM_TYPE_BYTE; > + #ifdef LIBFFIBUG > + method->data.native_method->args[i] =3D &ffi_type_uint; > + #else > method->data.native_method->args[i] =3D &ffi_type_sint8; > + #endif > i++; > } > break; > *************** > *** 333,339 **** > --- 337,347 ---- > case 'C': > { > method->data.native_method->arg_types[i] =3D SVM_TYPE_CHAR; > + #ifdef LIBFFIBUG > + method->data.native_method->args[i] =3D &ffi_type_uint; > + #else > method->data.native_method->args[i] =3D &ffi_type_uint16; > + #endif > i++; > } > break; > *************** > *** 357,363 **** > --- 365,375 ---- > case 'S': > { > method->data.native_method->arg_types[i] =3D SVM_TYPE_SHORT; > + #ifdef LIBFFIBUG > + method->data.native_method->args[i] =3D &ffi_type_uint; > + #else > method->data.native_method->args[i] =3D &ffi_type_sint16; > + #endif > i++; > } > break; > *************** > *** 365,371 **** > --- 377,387 ---- > case 'Z': > { > method->data.native_method->arg_types[i] =3D SVM_TYPE_BOOLEAN; > + #ifdef LIBFFIBUG > + method->data.native_method->args[i] =3D &ffi_type_uint; > + #else > method->data.native_method->args[i] =3D &ffi_type_uint8; > + #endif > i++; > } > break; > *************** > *** 904,910 **** > --- 920,930 ---- > case SVM_TYPE_BOOLEAN: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jboolean *) &result[0]) + 3); > + #else =20 > params[0].jint =3D *((jboolean *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 912,918 **** > --- 932,942 ---- > case SVM_TYPE_BYTE: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jbyte *) &result[0]) + 3); > + #else > params[0].jint =3D *((jbyte *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 920,926 **** > --- 944,954 ---- > case SVM_TYPE_SHORT: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jshort *) &result[0]) + 2); > + #else > params[0].jint =3D *((jshort *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 928,934 **** > --- 956,966 ---- > case SVM_TYPE_CHAR: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jchar *) &result[0]) + 2); > + #else > params[0].jint =3D *((jchar *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 1238,1247 **** > } > break; > =20 > ! case SVM_TYPE_BOOLEAN: > { > ! /* don't forget about little/big endian alignment */ > params[0].jint =3D *((jboolean *) &result[0]); > frame->stack_size++; > } > break; > --- 1270,1284 ---- > } > break; > =20 > ! case SVM_TYPE_BOOLEAN: =20 > { > !=20 > ! #ifdef LIBFFIBUG > ! params[0].jint =3D *(((jboolean *) &result[0]) + 3); > ! #else > params[0].jint =3D *((jboolean *) &result[0]); > + #endif > +=20 > frame->stack_size++; > } > break; > *************** > *** 1249,1255 **** > --- 1286,1296 ---- > case SVM_TYPE_BYTE: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jbyte *) &result[0]) + 3); > + #else > params[0].jint =3D *((jbyte *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 1257,1263 **** > --- 1298,1308 ---- > case SVM_TYPE_SHORT: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jshort *) &result[0]) + 2); > + #else > params[0].jint =3D *((jshort *) &result[0]); > + #endif > frame->stack_size++; > } > break; > *************** > *** 1265,1271 **** > --- 1310,1320 ---- > case SVM_TYPE_CHAR: > { > /* don't forget about little/big endian alignment */ > + #ifdef LIBFFIBUG > + params[0].jint =3D *(((jchar *) &result[0]) + 2); > + #else > params[0].jint =3D *((jchar *) &result[0]); > + #endif > frame->stack_size++; > } > break; > Index: sablevm-1.0.5/src/libsablevm/system.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/= system.c,v > retrieving revision 1.1.1.1 > diff -c -r1.1.1.1 system.c > *** sablevm-1.0.5/src/libsablevm/system.c 13 Dec 2002 01:52:11 -0000 1.= 1.1.1 > --- sablevm-1.0.5/src/libsablevm/system.c 18 Dec 2002 02:23:30 -0000 > *************** > *** 5,11 **** > * modification of SableVM. * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= ) && defined (__GNUC__)) > =20 > /* > ---------------------------------------------------------------------= - > --- 5,11 ---- > * modification of SableVM. * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= || defined (__powerpc__)) && defined (__GNUC__)) > =20 > /* > ---------------------------------------------------------------------= - > *************** > *** 109,114 **** > --- 109,144 ---- > result =3D __sync_bool_compare_and_swap (pword, old_value, new_valu= e); > =20 > #endif > +=20 > + #if (defined (__powerpc__)) > +=20 > + int result; > +=20 > + /* > + * Adapted from the glibc-linuxthreads, file pt-machine.h > + * > + */ > + __asm__ __volatile__ ( > + "0: lwarx %0,0,%1 ;" > + " xor. %0,%3,%0;" > + " bne 1f;" > + " stwcx. %2,0,%1;" > + " bne- 0b;" > + "1: " > + : "=3D&r"(result) > + : "r"(pword), "r"(new_value), "r"(old_value) > + : "cr0", "memory"); > + /* This version of __compare_and_swap is to be used when acquiring > + a lock, so we don't need to worry about whether other memory > + operations have completed, but we do need to be sure that any lo= ads > + after this point really occur after we have acquired the lock. = */ > + __asm__ __volatile__ ("isync" : : : "memory"); > +=20 > + /* flip the value of result */ > + result =3D !result; > +=20 > + #endif > +=20 > =20 > return result ? JNI_TRUE : JNI_FALSE; > } > Index: sablevm-1.0.5/src/libsablevm/system.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/= system.h,v > retrieving revision 1.1.1.1 > diff -c -r1.1.1.1 system.h > *** sablevm-1.0.5/src/libsablevm/system.h 13 Dec 2002 01:52:11 -0000 1.= 1.1.1 > --- sablevm-1.0.5/src/libsablevm/system.h 18 Dec 2002 02:30:27 -0000 > *************** > *** 48,54 **** > =20 > */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= ) && defined (__GNUC__)) > =20 > /* "inline" is now an official keyword since the latest C standard (1= 999). > So, it is a reasonable assuption to expect a target compiler to > --- 48,54 ---- > =20 > */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= || defined (__powerpc__)) && defined (__GNUC__)) > =20 > /* "inline" is now an official keyword since the latest C standard (1= 999). > So, it is a reasonable assuption to expect a target compiler to > *************** > *** 100,107 **** > --- 100,120 ---- > #define SVM_ALIGNMENT_POWER 3 /* 2 ^^ SVM_ALIGNMENT_POWER =3D=3D SVM_= ALIGNMENT */ > #define SVM_PAGE_SIZE 16384 > =20 > + #elif defined (__powerpc__) > +=20 > + typedef _svmt_u32 _svmt_word; > +=20 > + #define SVM_WORD_SIZE 4 /* size in bytes */ > + #define SVM_WORD_BIT_COUNT 32 /* size in bits */ > +=20 > + /* see comments at the head of this file */ > + #define SVM_ALIGNMENT 8 > + #define SVM_ALIGNMENT_POWER 3 /* 2 ^^ SVM_ALIGNMENT_POWER =3D=3D SVM_= ALIGNMENT */ > + #define SVM_PAGE_SIZE 4096 > +=20 > #endif > =20 > +=20 > /* FFI specific types */ > #define ffi_type_float32 ffi_type_float > #define ffi_type_float64 ffi_type_double > *************** > *** 163,165 **** > --- 176,179 ---- > #endif > =20 > #endif /* not SVM_SYSTEM_H */ > +=20 > Index: sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/david/cvsroot/sablevm_ppc/sablevm-1.0.5/src/libsablevm/= include/jni_system_specific.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.2 > diff -c -r1.1.1.1 -r1.2 > *** sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h 13 Dec 2= 002 01:52:11 -0000 1.1.1.1 > --- sablevm-1.0.5/src/libsablevm/include/jni_system_specific.h 13 Dec 2= 002 19:58:44 -0000 1.2 > *************** > *** 15,21 **** > =20 > /* alpha and i386 are identical here */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= ) && defined (__GNUC__)) > =20 > #define JNICALL > #define JNIEXPORT > --- 15,21 ---- > =20 > /* alpha and i386 are identical here */ > =20 > ! #if ((defined (__ia64__) || defined (__alpha__) || defined (__i386__)= || defined (__powerpc__)) && defined (__GNUC__)) > =20 > #define JNICALL > #define JNIEXPORT > Index: sablevm-native-library-1.0.5/src/include/jni_system_specific.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/david/cvsroot/sablevm_ppc/sablevm-native-library-1.0.5/= src/include/jni_system_specific.h,v > retrieving revision 1.1.1.1 > retrieving revision 1.2 > diff -c -r1.1.1.1 -r1.2 > *** sablevm-native-library-1.0.5/src/include/jni_system_specific.h 13 D= ec 2002 01:52:11 -0000 1.1.1.1 > --- sablevm-native-library-1.0.5/src/include/jni_system_specific.h 13 D= ec 2002 19:59:23 -0000 1.2 > *************** > *** 8,14 **** > =20 > /* system specific primitive types */ > =20 > ! #if (defined (__i386__) && defined (__GNUC__)) > =20 > /* legend: > u =3D unsigned intger, s =3D signed integer, f =3D float, d =3D d= ouble > --- 8,14 ---- > =20 > /* system specific primitive types */ > =20 > ! #if ((defined (__i386__) || defined (__powerpc__)) && defined (__GNUC= __)) > =20 > /* legend: > u =3D unsigned intger, s =3D signed integer, f =3D float, d =3D d= ouble --=20 Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-18 05:42:54
|
Etienne, I am sending the powerpc patch I have. The patch is against release 1.0.5. Let me know the correct/prefered patch format, I am not=20 familiar with diff/patch. It was not heavily tested yet. I'm not sure if the libffi bug work around works 100%. Other parts should be correct. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-17 04:37:06
|
On Mon, Dec 16, 2002 at 04:30:47PM -0800, Archie Cobbs wrote: > I'm not sure how to fix this.. the code for INVOKEINTERFACE calls > _svmf_resolve_CONSTANT_InterfaceMethodref() to resolve the interface > method, but it seems redundant now. Or perhaps INVOKEVIRTUAL needs to > check if the returned method is an interface method and act accordingly. I will investigate this. As long as the argument to INVOKEINTERFACE is a valid CONSTANT_Methodref, it is a SableVM bug. Otherwise, it is a compiler bug (unlikely). Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2002-12-17 00:45:04
|
Archie Cobbs wrote:
> public class Bar {
> public static void main(String[] args) {
> new soot.jimple.internal.JimpleLocalBox(null).setValue(null);
> }
> }
>
> I get this crash:
>
> assertion "_svmf_is_assignable_from (env, instance->vtable->type, _svmf_cast_type_class (method->class_info))" failed: file "instructions_preparation_direct_threaded.c", line 17953
The problem seems to be this... the soot-1.2.4 classes are compiled
with a Java compiler (I don't know which one) that uses INVOKEVIRTUAL
when calling a method M in a subclass B that extends an abstract
class A that implements an interface I, where M is not implemented in
A (and therefore abstract in A) but is implemented in B.
Above, A = AbstractValueBox, B = JimpleLocalBox, I = ValueBox, and
M = canContainValue(). The code for JimpleLocalBox.setValue() invokes
the method "AbstractValueBox.canContainValue()" using INVOKEVIRTUAL.
The problem with SableVM is that it calls _svmf_resolve_CONSTANT_Methodref()
to resolve the INVOKEVIRUTAL method reference, but it's possible for
_svmf_resolve_CONSTANT_Methodref() to return an interface method. That's
what happens in the above example.
But the code for PREPARE_INVOKEVIRTUAL does not handle that; it expects
a non-interface method and so when the method_id is some huge value we
get a crash.
I'm not sure how to fix this.. the code for INVOKEINTERFACE calls
_svmf_resolve_CONSTANT_InterfaceMethodref() to resolve the interface
method, but it seems redundant now. Or perhaps INVOKEVIRTUAL needs to
check if the returned method is an interface method and act accordingly.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: Archie C. <ar...@de...> - 2002-12-16 23:30:05
|
Hi,
I'm completely stuck by a bug in SableVM which I'm trying to investigate.
As a simple sanity check, could someone else out there try to reproduce
the problem so I can make sure there's not something crazy/stupid that
I'm doing wrong?
Here's all you need to do:
1. Install sablevm 1.0.5
2. Install the soot-1.2.4 classes and put them in your classpath
http://www.sabel.mcgill.ca/software/soot-1.2.4.tar.gz
3. Run this program:
public class Bar {
public static void main(String[] args) {
new soot.jimple.internal.JimpleLocalBox(null).setValue(null);
}
}
I get this crash:
assertion "_svmf_is_assignable_from (env, instance->vtable->type, _svmf_cast_type_class (method->class_info))" failed: file "instructions_preparation_direct_threaded.c", line 17953
Thanks!
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: Etienne M. G. <eti...@uq...> - 2002-12-14 06:30:18
|
On Fri, Dec 13, 2002 at 11:56:57PM +0100, Grzegorz Prokopski wrote: > Hi! > > I finally got some time this evening and wanted to finalize the > work on ia64 port. I wanted to do it other way round (I mean - not > using debs) so I fetched all three archives, copied build and > build-many scripts into the dir where archives reside. > Then I ran: > > gadek@merulo:~/sable4$ ./build-many /home/gadek/sable4/local > > And I am getting this: The build-many script is meant to decompress and compile the .tar.gz archives. For some reason, it seems the GNU m4 generated files are missing (yet they should be in the .tar.gz archives). If you want to build sablevm from a CVS snapshot, try instead: aclocal ; libtoolize ; autoconf ; autoheader ; automake --foreign -a =2E/configure \ --prefix=3D/home/egagnon/work \ --program-suffix=3D-debug \ --libdir=3D/home/egagnon/work/lib/sablevm-debug \ --enable-debugging-features \ --disable-signals-for-exceptions \ --with-gc=3Dcopying \ --with-obj-layout=3Dbidirectional \ --with-threading=3Dswitch make ; make install ; etags -R This builds a "debug" version. (You might want to look at Archie's patch to keep symbols around). Of course you might want to replace "/home/egagnon/work" by something more appropriate, and specify different configure options. Try "./configure --help" [after running "aclocal ; libtoolize ; autoconf ; autoheader ; automake --foreign -a"]. > PS: Etienne - if you cold join the irc for a moment maybe... > (especially if the anwer to the above isn't clear) I was watching exams all afternoon and evening (and busy answering students questions in the morning)... So, I didn't read your message soon enough. :( Have fun! Etienne --=20 Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-14 01:32:49
|
Hello, I will send a bug report to the libffi2 maintainers. I found another bug about libffi2. It does not passed properly args of type ffi_type_uint8. I will patch the code temporarily as suggested by Etienne to get around these bugs. David On Fri, Dec 13, 2002 at 05:49:16PM -0500, Etienne M. Gagnon wrote: > On Fri, Dec 13, 2002 at 05:18:42PM -0500, David Paul BELANGER wrote: > > Accessing the value simply with: > > params[0].jint =3D result[0].jint; > >... > > The other possible fix is to take byte at offset 3 for big endian > > machines: > > *(((unsigned char*) &v) + 3) > > this does not rely on the layout of the union in memory. >=20 > Yes, it actually does! So, this would be wrong, as libffi was given > ((unsigned char*) &v) as the location to store a "char", not and > "int". So, SableVM's source code is correct. >=20 > "params[0].jint =3D result[0].jint;" should fail on a big-endian > machine! (It makes sense for this code *not* to work on both big and > little-endian machines, if a "char" value was stored at &result). >=20 > Maybe we should add an "#if defined(LIBFFIBUG) ... #endif" clause with > the temporary bug evasion for now, and submit a bug against libffi > (try "reportbug libffi2" on Debian, assuming reportbug is installed). >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Archie C. <ar...@de...> - 2002-12-14 01:15:07
|
Archie Cobbs wrote: > > Note the absurd 'frame_size=178286532' value being passed to > > _svmf_ensure_stack_capacity() (because of the first bug, it actually > > tries to allocate that much memory, but nevermind that for a minute)... > > This value results from a corrupted 'method' structure. It appears > > that the 'method->frame_info' pointer is bogus: > > Further progress report on this... Now I've gotten this: $ sablevm Foo Test Transforming Test... assertion "_svmf_is_assignable_from (env, instance->vtable->type, _svmf_cast_type_class (method->class_info))" failed: file "instructions_preparation_direct_threaded.c", line 17953 Abort(core dumped) Wondering if this is a FreeBSD problem, I tried running on Linux: $ cat > .gdbinit file /usr/local/bin/sablevm-debug set args --verbose-gc soot.Main --jimple Test run break _svmf_error_OutOfMemoryError break _svmf_error_OutOfMemoryError_msg $ gdb GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". No ssh-agent found. [New Thread 1024 (LWP 2869)] [verbose gc: allocating fixed size heap (2 * 16777216 bytes)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2869)] 0x400351e2 in _svmf_invoke_native_nonstatic (env=0x804e2a0) at native.c:1293 1293 params[0].reference = *obj; Breakpoint 1 at 0x4001e622: file error_throwing.c, line 2501. Breakpoint 2 at 0x4001e75a: file error_throwing.c, line 2566. (gdb) c Continuing. Cannot find user-level thread for LWP 2869: generic error (gdb) c Continuing. Cannot find thread 1024: generic error $ sablevm-debug --verbose-gc soot.Main --jimple Test [verbose gc: allocating fixed size heap (2 * 16777216 bytes)] Segmentation fault $ uname -a Linux foobar5.packetdesign.com 2.4.18 #4 SMP Mon Oct 7 09:52:52 PDT 2002 i686 unknown Note: this is a 2-CPU machine. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
|
From: Grzegorz P. <ga...@de...> - 2002-12-13 22:59:08
|
Hi! I finally got some time this evening and wanted to finalize the work on ia64 port. I wanted to do it other way round (I mean - not using debs) so I fetched all three archives, copied build and build-many scripts into the dir where archives reside. Then I ran: gadek@merulo:~/sable4$ ./build-many /home/gadek/sable4/local And I am getting this: gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I./include -DBOOT_CLASS_PATH=3D\"/home/gadek/sable4/local/lib/sablevm-debug/sablevm/cl= asses-1.0.5\" -DBOOT_LIBRARY_PATH=3D\"/home/gadek/sable4/local/lib/sablevm-= debug/sablevm\" -g -O2 -Wall -fno-gcse -Wno-unused -std=3Diso9899:1990 -ped= antic -O0 -Werror -W -fno-builtin -Wshadow -Wpointer-arith -Wbad-function-c= ast -Wundef -Wcast-align -Wwrite-strings -Wsign-compare -Wstrict-prototypes= -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wlong-long -= c libsablevm.c -MT libsablevm.lo -MD -MP -MF .deps/libsablevm.TPlo -fPIC -= DPIC -o libsablevm.lo In file included from libsablevm.c:33: types.h:240:24: error_bits.h: No such file or directory types.h:273:27: error_classes.h: No such file or directory types.h:302:32: error_init_methods.h: No such file or directory types.h:337:29: error_instances.h: No such file or directory libsablevm.c:36:26: global_alloc.h: No such file or directory libsablevm.c:41:22: cl_alloc.h: No such file or directory libsablevm.c:48:27: method_invoke.h: No such file or directory libsablevm.c:51:18: cast.c: No such file or directory libsablevm.c:53:18: util.c: No such file or directory libsablevm.c:57:28: error_throwing.c: No such file or directory libsablevm.c:58:26: global_alloc.c: No such file or directory libsablevm.c:66:27: method_invoke.c: No such file or directory libsablevm.c:70:22: cl_alloc.c: No such file or directory libsablevm.c:71:31: class_file_parser.c: No such file or directory libsablevm.c:72:24: splay_tree.c: No such file or directory libsablevm.c:77:30: native_interface.c: No such file or directory In file included from libsablevm.c:78: interpreter.c:165:33: instructions_switch.c: No such file or directory interpreter.c:431:54: instructions_preparation_switch_threaded.c: No such file or directory In file included from libsablevm.c:83: invoke_interface.c:184:21: vm_args.c: No such file or directory make[3]: *** [libsablevm.lo] Error 1 make[3]: Leaving directory `/home/gadek/sable4/sablevm-1.0.5/src/libsablevm' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/gadek/sable4/sablevm-1.0.5/src/libsablevm' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/gadek/sable4/sablevm-1.0.5/src' make: *** [install-recursive] Error 1 ln: creating symbolic link `/home/gadek/sable4/local/lib/sablevm-debug/sablevm' to `/home/gadek/sable4/local/lib/sablevm/debug-lib/sablevm': No such file or directory It seems that it cannot find error_bits.h. After taking closer look I found out that all error*.m4.* files didn't produce the resulting *.h and *.c files! Is this my fault somewhere? Hmm... after even more close look I can say that most of *.m4.* files didn't produce needed resulting *.h and *.c. So build didn't have much chances to be completed. I haven't used build-many script yet... Grzegorz B. Prokopski PS: Etienne - if you cold join the irc for a moment maybe... (especially if the anwer to the above isn't clear) |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 22:55:03
|
On Fri, Dec 13, 2002 at 05:18:42PM -0500, David Paul BELANGER wrote: > Accessing the value simply with: > params[0].jint = result[0].jint; >... > The other possible fix is to take byte at offset 3 for big endian > machines: > *(((unsigned char*) &v) + 3) > this does not rely on the layout of the union in memory. Yes, it actually does! So, this would be wrong, as libffi was given ((unsigned char*) &v) as the location to store a "char", not and "int". So, SableVM's source code is correct. "params[0].jint = result[0].jint;" should fail on a big-endian machine! (It makes sense for this code *not* to work on both big and little-endian machines, if a "char" value was stored at &result). Maybe we should add an "#if defined(LIBFFIBUG) ... #endif" clause with the temporary bug evasion for now, and submit a bug against libffi (try "reportbug libffi2" on Debian, assuming reportbug is installed). Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2002-12-13 22:30:03
|
Archie Cobbs wrote: > Note the absurd 'frame_size=178286532' value being passed to > _svmf_ensure_stack_capacity() (because of the first bug, it actually > tries to allocate that much memory, but nevermind that for a minute)... > This value results from a corrupted 'method' structure. It appears > that the 'method->frame_info' pointer is bogus: Further progress report on this... It appears that SableVM is trying to run the START_PREPARE_INVOKEVIRTUAL "bytecode" using a '_svmt_CONSTANT_Methodref_info' which describes an interface method instead of an instance method. The result is that the computed method_id is 616 which of course is supposed to be an interface method index but SableVM tries to use it as a virtual method index to the vtable, hence the 'corrupted method' and crash. The method being executed is soot.AbstractValueBox.setValue(). The interface method that this method is trying to invoke is soot.ValueBox.canContainValue(). So in summary, a concrete method (setValue()) in an abstract class (AbstractValueBox) that implements an interface (ValueBox) is trying to invoke an abstract interface method (canContainValue()) using the 'this' object. Hopefully this rings a bell.. ? I haven't been able to reproduce this with a simple example. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 22:19:03
|
On Fri, Dec 13, 2002 at 02:46:53PM -0500, David Paul BELANGER wrote: > > Hello, > > There something I don't quite get > > native.c around line 1240: > > Original code (does not work on PPC): > case SVM_TYPE_BOOLEAN: > params[0].jint = *((jboolean *) &result[0]); > > > Could it be simply replaced by (works on PPC): > params[0].jint = result[0].jint; > instead? > > or is the address taken, cast, deference for some reason? I guess it > depends on how the data is stored in _svmt_stack_value_union by ffi_call > and how the union is layed out in memory? libffi is supposed to be returning a boolean (i.e. "char") value at the location &result [at least, this is what I understood from the documentation]. So, *((jboolean *) &result[0]) seems to be "the right way" to extract the returned boolean value. Nowhere, in the libffi doc, have I see any special note about handling sub-32bits values specially (because of alignment constraints), so I suspect libffi is buggy. Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David P. B. <db...@CS...> - 2002-12-13 22:18:46
|
I found the source of the problem: If you have: int v =3D 0x1234ABCD; On x86: (unsigned char) v and (unsigned char*) &v are both equivalent. Both will return byte 0 of the word which 0xCD which is correct. On PowerPC (big endian) (unsigned char) v and *((unsigned char*) &v) are different. The first one will return correctly byte 3 that is 0xCD. But the 2nd one returns byte 0 which is 0x12 on a big endian. Accessing the value simply with: params[0].jint =3D result[0].jint; instead of params[0].jint =3D *((jboolean *) &result[0]); =20 and this should work if the field jint is always located at the beginning= of the union in memory. The other possible fix is to take byte at offset 3 for big endian machines: *(((unsigned char*) &v) + 3) this does not rely on the layout of the union in memory. David On Thu, Dec 12, 2002 at 08:14:46PM -0500, Etienne M. Gagnon wrote: > On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote: > > Hi, > >=20 > > I got HelloWorld to work on sablevm 1.0.5! >=20 > This is really great! So, were there any endianness problem you had to= fix? >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: David P. B. <db...@CS...> - 2002-12-13 19:46:59
|
Hello,
There something I don't quite get
native.c around line 1240:
Original code (does not work on PPC):
case SVM_TYPE_BOOLEAN:
params[0].jint =3D *((jboolean *) &result[0]);
Could it be simply replaced by (works on PPC):
params[0].jint =3D result[0].jint;
instead?
or is the address taken, cast, deference for some reason? I guess it
depends on how the data is stored in _svmt_stack_value_union by ffi_call
and how the union is layed out in memory?
David
On Thu, Dec 12, 2002 at 08:14:46PM -0500, Etienne M. Gagnon wrote:
> On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote:
> > Hi,
> >=20
> > I got HelloWorld to work on sablevm 1.0.5!
>=20
> This is really great! So, were there any endianness problem you had to=
fix?
>=20
> Etienne
>=20
> --=20
> Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/
> SableVM: http://www.sablevm.org/
> SableCC: http://www.sablecc.org/
--=20
---
David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226
Web page: http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
|
|
From: Archie C. <ar...@de...> - 2002-12-13 19:30:09
|
Etienne M. Gagnon wrote:
> > I've upgraded Soot from 1.2.3 to 1.2.4 and now I'm having a problem
> > running it with SableVM (version 1.0.5).
> >
> > The problem is that the sablevm process seems to eat up an infinite
> > amount of memory, bringing my machine to a grinding, thrashing halt.
> >
> > I've tried to limit sablevm by adding this to my ~/.sablevm file:
> >
> > property = sablevm.heap.size.increment=0
> > property = sablevm.heap.size.min=16777216
> > property = sablevm.heap.size.max=16777216
> > property = sablevm.classloader.heap.size.increment=0
> > property = sablevm.classloader.heap.size.min=16777216
> > property = sablevm.classloader.heap.size.max=16777216
> >...
>
> That was a good idea.
>
> Now, it seems we need to know which allocation site is causing these
> problems. You might want to poke around using electric-fence (and/or
> other malloc debuggers) to try identifying the leaking site.
Here's some more info on this problem.
First of all, I was forgetting to limit the stack growth. So I added
these lines to ~/.sablevm:
property = sablevm.stack.size.increment=4194304
property = sablevm.stack.size.min=4194304
property = sablevm.stack.size.max=33554432
However, setting 'sablevm.stack.size.max' doesn't actually do anthing...
You can verify this by reviewing the code for uses of 'vm->stack_max_size'.
This variable is never actually used, so no matter what the properties
are set to, there is no bound to the stack growth of any thread.
Aside from that, there is some other memory corruption bug.
Here is a GDB stack trace:
#4 0x2818bbdd in realloc () from /usr/lib/libc_r.so.4
#5 0x2806b2eb in _svmf_realloc (ptr=0xaca0000, size=180355072) at system.c:141
#6 0x28070ac8 in _svmf_ensure_stack_capacity (env=0x8061900,
frame_size=178286532) at thread.c:238
#7 0x280c65ad in _svmf_interpreter (_env=0x8061900)
at instructions_preparation_direct_threaded.c:17986
#8 0x28079098 in _svmh_invoke_static_virtualmachine_runthread (env=0x8061900)
at method_invoke.c:4941
#9 0x280710ff in _svmf_thread_start (_env=0x8061900) at thread.c:1028
#10 0x281197e3 in _thread_start () from /usr/lib/libc_r.so.4
#11 0x0 in ?? ()
Note the absurd 'frame_size=178286532' value being passed to
_svmf_ensure_stack_capacity() (because of the first bug, it actually
tries to allocate that much memory, but nevermind that for a minute)...
This value results from a corrupted 'method' structure. It appears
that the 'method->frame_info' pointer is bogus:
(gdb) frame 7
#7 0x280c65ad in _svmf_interpreter (_env=0x8061900)
at instructions_preparation_direct_threaded.c:17986
17986 if (_svmf_ensure_stack_capacity
(gdb) list
17981
17982 frame->stack_size = stack_size;
17983 instance = stack[stack_size].reference;
17984 }
17985
17986 if (_svmf_ensure_stack_capacity
17987 (env, frame_info->java_invoke_frame_size) != JNI_OK)
17988 {
17989 goto exception_handler;
17990 }
(gdb) p *frame
$14 = {previous_offset = 40, end_offset = 48, method = 0xaa07244,
stack_trace_element = 0x0, lock_count = 0, this = 0x90309d0, pc = 0xaa07d20,
stack_size = 0}
(gdb) p *method
$15 = {access_flags = 10, name = 0xaa06bc4, descriptor = 0xaa06c2c,
attributes_count = 0, attributes = 0x0, class_info = 0x8,
method_id = 178285632, synchronized = 0, java_args_count = 10,
parameters_gc_map = 0xaa06bc4, frame_info = 0xaa06c44, prepared_info = {
code = 0x0, non_parameter_ref_locals_count = 0, start_offset = 10,
end_offset = 178285508, java_invoke_frame_size = 178285640,
internal_invoke_frame_size = 0}, non_prepared_info = {code = 0x0,
non_parameter_ref_locals_count = 8, start_offset = 178285644,
end_offset = 0, java_invoke_frame_size = 8,
internal_invoke_frame_size = 178285648}, reflection_instance = 0x0,
data = {code_attribute = 0xa, native_method = 0xa}}
(gdb) p *method->frame_info
$16 = {code = 0xaa06f78, non_parameter_ref_locals_count = 178286468,
start_offset = 178286480, end_offset = 178286516,
java_invoke_frame_size = 178286532, internal_invoke_frame_size = 178286544}
(gdb) x/64w 0xaa06c00
0xaa06c00: 0x0aa06de0 0x0aa06dfc 0x0aa06e10 0x0aa06e20
0xaa06c10: 0x0aa06e34 0x0aa06e50 0x0aa06e68 0x0aa06e84
0xaa06c20: 0x0aa06e9c 0x0aa06eb8 0x0aa06ed0 0x0aa06ef4
0xaa06c30: 0x0aa06f00 0x0aa06f0c 0x0aa06f18 0x0aa06f40
0xaa06c40: 0x0aa06f64 0x0aa06f78 0x0aa06f84 0x0aa06f90
0xaa06c50: 0x0aa06fb4 0x0aa06fc4 0x0aa06fd0 0x0aa06fe0
0xaa06c60: 0x0aa06fec 0x0aa06ff8 0x0aa0701c 0x0aa0703c
0xaa06c70: 0x0aa07058 0x0aa07074 0x0aa07090 0x0aa070a4
0xaa06c80: 0x0aa070e0 0x0aa0711c 0x0aa07134 0x0aa07154
0xaa06c90: 0x0aa0716c 0x0aa07190 0x0000000a 0x0aa06bf4
0xaa06ca0: 0x0aa06c2c 0x0a08afc4 0x00000000 0x0000000a
0xaa06cb0: 0x0aa06bf0 0x0aa06c30 0x0aa077e8 0x00000000
0xaa06cc0: 0x00000009 0x0aa06bf0 0x0aa06c34 0x00000000
0xaa06cd0: 0x00000000 0x00000007 0x0aa06c38 0x00000000
0xaa06ce0: 0x00000000 0x00000007 0x0aa06c3c 0x00000000
0xaa06cf0: 0x00000000 0x0000000a 0x0aa06bc4 0x0aa06c2c
I'll keep investigating and report any more info.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 06:18:15
|
On Fri, Dec 13, 2002 at 01:09:30AM -0500, Etienne M. Gagnon wrote: > Now, it seems we need to know which allocation site is causing these > problems. You might want to poke around using electric-fence (and/or > other malloc debuggers) to try identifying the leaking site. Ooops. libefence is probably not of much use for memory leaks. You might want to try memprof instead. http://people.redhat.com/~otaylor/memprof/index.html Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 06:12:24
|
On Thu, Dec 12, 2002 at 05:02:24PM -0800, Archie Cobbs wrote: > I've upgraded Soot from 1.2.3 to 1.2.4 and now I'm having a problem > running it with SableVM (version 1.0.5). > > The problem is that the sablevm process seems to eat up an infinite > amount of memory, bringing my machine to a grinding, thrashing halt. > > I've tried to limit sablevm by adding this to my ~/.sablevm file: > > property = sablevm.heap.size.increment=0 > property = sablevm.heap.size.min=16777216 > property = sablevm.heap.size.max=16777216 > property = sablevm.classloader.heap.size.increment=0 > property = sablevm.classloader.heap.size.min=16777216 > property = sablevm.classloader.heap.size.max=16777216 >... That was a good idea. Now, it seems we need to know which allocation site is causing these problems. You might want to poke around using electric-fence (and/or other malloc debuggers) to try identifying the leaking site. http://metalab.unc.edu/pub/Linux/devel/lang/c/ElectricFence-2.0.5.tar.gz On Debian: $ apt-get install electric-fence $ LD_PRELOAD=libefence.so sablevm soot.Main -O --jimple Test and $ man efence Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne M. G. <eti...@uq...> - 2002-12-13 01:20:18
|
On Thu, Dec 12, 2002 at 08:09:23PM -0500, David Paul BELANGER wrote: > Hi, > > I got HelloWorld to work on sablevm 1.0.5! This is really great! So, were there any endianness problem you had to fix? Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2002-12-13 01:15:04
|
I've upgraded Soot from 1.2.3 to 1.2.4 and now I'm having a problem
running it with SableVM (version 1.0.5).
The problem is that the sablevm process seems to eat up an infinite
amount of memory, bringing my machine to a grinding, thrashing halt.
I've tried to limit sablevm by adding this to my ~/.sablevm file:
property = sablevm.heap.size.increment=0
property = sablevm.heap.size.min=16777216
property = sablevm.heap.size.max=16777216
property = sablevm.classloader.heap.size.increment=0
property = sablevm.classloader.heap.size.min=16777216
property = sablevm.classloader.heap.size.max=16777216
Here's what happens:
$ sablevm --verbose-gc soot.Main -O --jimple Test
[verbose gc: allocating fixed size heap (2 * 16777216 bytes)]
Soot started on Fri Dec 13 00:53:14 GMT 2002
[verbose gc: previously allocated 16764392 bytes, surviving 4175580 bytes, new heap is 16777216 bytes, gc time = 0 sec 161959 usec]
[verbose gc: previously allocated 16767392 bytes, surviving 6926324 bytes, new heap is 16777216 bytes, gc time = 0 sec 252533 usec]
Transforming Test... ^C^C
At that point I killed sablevm because the system was going to
kill it anyway when it ran out of swap. The last top(1) snapshot
showed this:
last pid: 566; load averages: 0.33, 0.25, 0.19 up 0+00:34:11 16:54:00
70 processes: 1 running, 69 sleeping
CPU states: 3.1% user, 0.0% nice, 44.2% system, 0.8% interrupt, 51.9% idle
Mem: 103M Active, 952K Inact, 18M Wired, 312K Cache, 22M Buf, 492K Free
Swap: 133M Total, 60M Used, 73M Free, 45% Inuse, 248K Out
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
566 archie 28 0 179M 90108K pfault 0:25 46.27% 42.29% sablevm
...
Notice sablevm is using 179M of memory! Any ideas how to fix this?
And what is different about the new version of Soot that triggers this?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
|
From: David P. B. <db...@CS...> - 2002-12-13 01:09:26
|
On Fri, Dec 13, 2002 at 12:04:09AM +0100, Mark Wielaard wrote: > Hi, >=20 > On Thu, 2002-12-12 at 18:49, David Paul BELANGER wrote: > > I tried to port sableVM to the powerpc. I got it to compile. But it > > cannot execute a simple hello program. It stops and prints: > > java/lang/ExceptionInInitializer > > I does not even get to execute main. > >=20 > > I heard from Etienne that someone else was working on a powerpc port.= I > > would like to know its current state and, if it gets to execute the > > HelloWorld program, I would like to have the source code/patch even i= f > > it is still unstable. >=20 > A while ago I made some patches that got Hello World working on powerpc= : > http://sourceforge.net/mailarchive/forum.php?thread_id=3D983089&forum_i= d=3D4154 > http://sourceforge.net/mailarchive/message.php?msg_id=3D1997083 > http://sourceforge.net/mailarchive/forum.php?thread_id=3D1006086&forum_= id=3D4154 >=20 > They got never applied to the main source tree though. SableVM seems to > have some other endian issues with invoking native code through JNI. >=20 > Please let me know if the patches in those message still apply against > the current tree and make at least Hello World work. I would love to > have a working SableVM on powerpc but just don't have to time to hack o= n > it (and this was the first time I did anything in powerpc assembly so I > am not the best person to move this port forward). >=20 Hi, I got HelloWorld to work on sablevm 1.0.5! I got it to work by applying your patch for native.c to the code I have previously hacked. Now I will compare your patches for the other parts with mine and run more tests. Thanks, David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Mark W. <ma...@kl...> - 2002-12-12 23:05:11
|
Hi, On Thu, 2002-12-12 at 18:49, David Paul BELANGER wrote: > I tried to port sableVM to the powerpc. I got it to compile. But it > cannot execute a simple hello program. It stops and prints: > java/lang/ExceptionInInitializer > I does not even get to execute main. > > I heard from Etienne that someone else was working on a powerpc port. I > would like to know its current state and, if it gets to execute the > HelloWorld program, I would like to have the source code/patch even if > it is still unstable. A while ago I made some patches that got Hello World working on powerpc: http://sourceforge.net/mailarchive/forum.php?thread_id=983089&forum_id=4154 http://sourceforge.net/mailarchive/message.php?msg_id=1997083 http://sourceforge.net/mailarchive/forum.php?thread_id=1006086&forum_id=4154 They got never applied to the main source tree though. SableVM seems to have some other endian issues with invoking native code through JNI. Please let me know if the patches in those message still apply against the current tree and make at least Hello World work. I would love to have a working SableVM on powerpc but just don't have to time to hack on it (and this was the first time I did anything in powerpc assembly so I am not the best person to move this port forward). Cheers, Mark |
|
From: David P. B. <db...@CS...> - 2002-12-12 17:49:08
|
Hi, I tried to port sableVM to the powerpc. I got it to compile. But it cannot execute a simple hello program. It stops and prints: java/lang/ExceptionInInitializer I does not even get to execute main. I heard from Etienne that someone else was working on a powerpc port. I would like to know its current state and, if it gets to execute the HelloWorld program, I would like to have the source code/patch even if it is still unstable. FYI, I will develop a JIT compiler for SableVM for my master degree. Emphasis will be made on portability. I am thinking of initally targetting the x86 and (PowerPC or Sparc) architectures. Thanks,=20 David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
6 messages has been excluded from this view by a project administrator.
