This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: libffi on IA64 HP-UX
- From: Richard Henderson <rth at redhat dot com>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org, hans dot boehm at hp dot com
- Date: Sun, 20 Mar 2005 11:02:51 -0800
- Subject: Re: Patch: libffi on IA64 HP-UX
- References: <200503182347.PAA26649@hpsje.cup.hp.com>
On Fri, Mar 18, 2005 at 03:47:05PM -0800, Steve Ellcey wrote:
> The main change needed was to fix an inconsistency between ffi_call_unix
> and ffi_closure_unix. ffi_call_unix extended 8, 16, and 32 bit integer
> values to 64 bits before storing them in memory but ffi_closure_unix
> simply loaded the 8, 16, or 32 bits from memory without any extending.
> This worked on little-endian Linux but not on big-endian HP-UX. My fix
> is to have ffi_closure_unix do a full 64 bit load in all these cases
> since that is what ffi_call_unix stored.
Well, bad language; ffi_closure_unix is not related to ffi_call_unix
in any way. But since there's an (apparently) unwritten rule that a
user of libffi modify an entire ffi_arg when return integer data, this
change appears to be safe. Presuming that the user zero- or sign-
extendeds the data to at least 32-bits.
> + #ifdef _ILP32
> + addp4 gp = 0, gp
> + ;;
> + #endif
> /* Retrieve closure pointer and real gp. */
> mov out0 = gp
> add gp = 16, gp
Perhaps better as
/* Retrieve closure pointer and real gp. */
#ifdef _ILP32
addp4 out0 = 0, gp
addp4 gp = 16, gp
#else
mov out0 = gp
add gp = 16, gp
#endif
I'm not familiar enough with the ilp32 conventions ot know for sure,
but I do wonder if either (1) gp ought to already be pointer-extended
or (2) out0 need not be extended for the "ffi_closure *closure" argument.
r~