JNI in GCJ 3.2 for Win32

[Tom Tromey]

>>>>> "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