FW: libffi on HP-UX

["Boehm, Hans" <hans dot boehm at hp dot com>]

Steve Ellcey ran into an old, but previously unresolved problem
while working on a port to HP/UX.

The issue is how small integer values are returned from a libffi
call.
When an 8-bit integer is returned is an 8, 32, or 64-bit value
written through the result pointer?

This matters mostly only on big-endian targets.

Currently the documentation doesn't specify this very well at all.
Platforms seem to differ a bit in what they do.  The IA64 code
is internally inconsistent, in ways that matter on a big-endian
target like HP/UX.  (This is unsurprising, since it was written for
Linux, which is little-endian on IA64.)

My impression is that most of the client code presumes that char,
short, and int are returned as int, and everything else is returned
using the actual data size.  Effectively, the C "integral promotions"
are applied to the return type.  Is that the intended convention?
If that's unclear, can we make it the intended convention?

The last message on this topic that I could find is

http://gcc.gnu.org/ml/java/2002-10/msg00001.html

Hans

-----Original Message-----
From: Boehm, Hans 
Sent: Tuesday, February 15, 2005 12:12 PM
To: 'Steve Ellcey'
Cc: Boehm, Hans
Subject: RE: libffi on HP-UX


Unfortunately, the intent here is very unclear, since the interface
wasn't well-defined.  My reading is that the ffi_call_unix result value
should contain the promoted value of the result.  For 8, 16, and 32 bit
values, ffi_call_unix should store an int as the result. For 64-bit
values, it should be a long long.  I deduce this from the client code in
libjava/java/lang/reflect/natMethod.cc.

I found earlier discussion on this subject, but no clear resolution. I
think this means we're slightly wrong in both ffi_call_unix and
ffi_closure_unix.  (That's not too surprising.  I originally wrote this
code a long time ago assuming little-endian conventions.)

I think it would good to run this past the java@gcc.gnu.org mailing list
to get this resolved correctly.  Is it OK if I forward this?

Thanks.

Hans

> -----Original Message-----
> From: Steve Ellcey [mailto:sje@cup.hp.com]
> Sent: Tuesday, February 15, 2005 10:34 AM
> To: Boehm, Hans
> Subject: Re: libffi on HP-UX
> 
> 
> 
> OK, I think I understand my libffi problem.
> 
> If you look in ffi_call_unix where we are storing the return
> value (r8) of a function using .Lst_table, we extend 8/16/32 
> bit values to 64 bits and store the entire 64 bits.  In 
> ffi_closure_unix where we take the value out of memory and 
> put it back in r8 (using .Lld_table) we only load 8/16/32 
> bits and not the full 64 bits.  This means that on a 
> big-endian machine we get the wrong data.  We either need to 
> load all 64 bits in ffi_closure_unix or only store 8/16/32 
> bits in ffi_call_unix.
> 
> Any opinion on the right way to fix this?  My inclination
> would be to do a 64 bit load when restoring r8 in ffi_closure_unix.
> 
> Steve Ellcey
> sje@cup.hp.com
>