This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PATCH: libffi vs. SPARC (again)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, java-patches at gcc dot gnu dot org, green at redhat dot com
- Date: 16 Nov 2001 20:06:11 -0700
- Subject: Re: PATCH: libffi vs. SPARC (again)
- References: <Pine.LNX.4.10.10111160858500.30902-100000@mars.deadcafe.org>
- Reply-to: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
Jeff> 2) does this fix JNI, or just reflection?
It looks like Bryce's patch only touches the call used by reflection.
The fix really ought to be in the other _Jv_CallAnyMethodA.
Jeff> + switch (rtype->type)
Jeff> + {
Jeff> + case FFI_TYPE_VOID:
Jeff> + ffi_call (&cif, (void (*)()) meth->ncode, NULL, values);
Jeff> + break;
Jeff> [ ... ]
When I wrote JNI, I split _Jv_CallAnyMethodA into two pieces. Before
that it was a single function. In order to avoid a switch like this,
I used a local jvalue as the ffi_call return value in order to ensure
proper size and alignment for any result.
In a perfect world we'd go through the library and rethink things like
how we deal with signatures, and types, and the like. We have lots of
little bits of code that look similar but which are slightly different
(reflection, the interpreter, JNI, the verifier, and the class code
all have variants on the same stuff). It isn't fatal, but it does get
annoying. I'm mostly to blame for this :-(.
Tom