JNI in GCJ 3.2 for Win32

Sun Nov 10 12:58:00 GMT 2002

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit> a) The current implementation already synchronises on
Ranjit> global_ref_table.
Ranjit> b) What's wrong with returning the found function ptr?
I wrote the fix in (a) and then forgot I did it. So I'm at least
partly off track here.
But I think returning the function pointer is still incorrect. The
stub we generate in the compiler caches this function pointer in a
static variable. So I think that even though the lookup is correctly
synchronized, the store is not and could potentially cause problems.
That is, assuming that there is an architecture where a store of a
function pointer is not atomic. I don't know if that is the case.
Ranjit> I just want to tell the native compiler to pass another parameter
Ranjit> set to the real number of bytes passed as arguments to the called
Ranjit> function.
Ok.
Ranjit> I can't even seem to be able to trace where exactly it is specifying
Ranjit> the FFI ABI to use, leave alone making the change noted above. :-(
In expr.c:build_jni_stub():
 jni_func_type
 = build_pointer_type (build_function_type (TREE_TYPE (TREE_TYPE (method)),
					 arg_types));
This builds a type that represents the user's JNI function. I
imagine, but am not positive, that this is where you'd need to tell
gcc that the user's function is stdcall. Offhand I don't know how to
do this, but I would start by looking through the gcc code to see how
stdcall is handled by the C front end.
In decl.c:java_init_decl_processing():
 t = tree_cons (NULL_TREE, object_ptr_type_node,
		 tree_cons (NULL_TREE, ptr_type_node,
			 tree_cons (NULL_TREE, ptr_type_node, endlink)));
 soft_lookupjnimethod_node
 = builtin_function ("_Jv_LookupJNIMethod",
			build_function_type (ptr_type_node, t),
			0, NOT_BUILT_IN, NULL, NULL_TREE);
This is the equivalent of the declaration:
 extern void *_Jv_LookupJNIMethod (jobject, void *, void *);
You'd need to add some new code to the assignment to `t' to update the
type of the function.
Then back in build_jni_stub():
 jnifunc = build (COND_EXPR, ptr_type_node,
		 meth_var, meth_var,
		 build (MODIFY_EXPR, ptr_type_node,
			 meth_var,
			 build (CALL_EXPR, ptr_type_node,
				 build_address_of (soft_lookupjnimethod_node),
				 lookup_arg, NULL_TREE)));
This is the call to _Jv_LookupJNIMethod. You'd need to compute the
size of the arguments here. If you look a bit earlier in that
function you'll see some code that iterates over the methods. You
could do your computation there. I think something like
int_size_in_bytes(TREE_TYPE(arg)) will get you the info you want;
tree.h is a good (if cluttered) source for this sort of thing.
Tom