This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: libffi on IA64 HP-UX


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]