JNI in GCJ 3.2 for Win32
Sun Nov 10 12:58:00 GMT 2002
>>>>> "Ranjit" == Ranjit Mathew <firstname.lastname@example.org> writes:
Ranjit> a) The current implementation already synchronises on
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> 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. :-(
= build_pointer_type (build_function_type (TREE_TYPE (TREE_TYPE (method)),
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.
t = tree_cons (NULL_TREE, object_ptr_type_node,
tree_cons (NULL_TREE, ptr_type_node,
tree_cons (NULL_TREE, ptr_type_node, endlink)));
= 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,
build (MODIFY_EXPR, ptr_type_node,
build (CALL_EXPR, ptr_type_node,
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.
More information about the Java