PATCH: libffi vs. SPARC (again)

[Jeff Sturm]

On 14 Nov 2001, Tom Tromey wrote:

> >>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
> 
> Jeff> It stands to reason that if the return value must be one full
> Jeff> word, the return type must also reflect its size.
> 
> I don't follow the reasoning here.

Well, both ffitest.c and the README suggest a FFI_TYPE_SINT8 return value
will be promoted to an int, but don't say how (e.g. signedness, byte
order).  So the result is undefined, and can/will vary by target.

Similarly, what is the output of

  union {
    char c;
    int i;
  } u;

  u.i = 3;
  printf("%d\n", (int)u.c);

It would be reasonable to either handle byte-sized return values
explicity in ffi_call, or else forbid them altogether.  The former adds
code and complexity to libffi, the latter more closely aligned with how
microprocessors work: virtually all ABIs specify a word-sized register for
return values.

If I had my choice I'd steer towards a smaller, leaner, faster libffi that
does less processing of its arguments, e.g. the raw calls for x86.  But I
don't wish to open that particular can of worms just yet...

> With your patch, libgcj knows that `byte' (and other small integer)
> returns must be promoted to `int'.  It seems to me that this is an ABI
> issue.  And, if that is the case, then libffi properly should handle
> this case.

...that's a reasonable suggestion...

> In other words, suppose we change libffi to give an error if the
> return type is FFI_TYPE_SINT8.  Once we've done that, why not simply
> fix libffi to handle this piece of the ABI?

...except I fear it wouldn't be simple.  For one thing, any applications
that depend on the current behavior could begin to fail.  (That includes
ffitest.c, BTW.  Look at line 332 where a ffi_type_schar return type is
given with a (int *) return value.)

For another thing, changing libffi properly could not be done in any of
the machine-independent sources, so you'd touch every port.

Believe me, I started down this path and gave up after a couple of days,
abandoning my work on libffi and refocusing on natMethod.cc instead.  I
don't claim my patch is pretty, I really don't like it myself, but it
does fix a serious bug.

<sigh> I've already spent more time on this than I could afford right
now.  I've been patching my local solaris builds for the last six months.
Nobody else has fixed it yet.  If nothing breaks, can we please go with
this, at least for 3.1?

Jeff