GHC FFI Return Type Bug

[Julian Seward (Intl Vendor)]

Thanks.  I think the decision here is to do the safe thing
and mask the return results ourselves, since it's only one
extra insn.  This won't make it into 5.02, tho.

J

| -----Original Message-----
| From: Sigbjorn Finne [mailto:sof@galconn.com]=20
| Sent: Saturday, September 08, 2001 4:27 PM
| To: Julian Seward (Intl Vendor)
| Cc: partain@dcs.gla.ac.uk; Ashley Yakeley; GHC List
| Subject: Re: GHC FFI Return Type Bug
|=20
|=20
| Here's another data point on this topic - I asked around=20
| inside of MS, and the consensus is that the contents of the=20
| unused portions of EAX is undefined upon return (upper 3=20
| bytes for byte-sized return values, upper 2 for 16-bit=20
| values). This is invariant of x86 calling convention on Win32=20
| (cdecl,stdcall,fastcall). Still no known doc/spec which=20
| spells this out.
|=20
| =3D=3D> GHC's NCG and C backends need to know the sizes of the=20
| unboxed Ints and Words involved in CCalls to generate correct code.
|=20
| --sigbjorn
|=20
| ----- Original Message -----
| From: "Sigbjorn Finne" <sof@galconn.com>
| To: "Julian Seward (Intl Vendor)" <v-julsew@microsoft.com>
| Cc: <partain@dcs.gla.ac.uk>; "Ashley Yakeley"=20
| <ashley@semantic.org>; "GHC List" <glasgow-haskell-users@haskell.org>
| Sent: Tuesday, August 07, 2001 16:00
| Subject: Re: GHC FFI Return Type Bug
|=20
|=20
| >
| > "Julian Seward (Intl Vendor)" <v-julsew@microsoft.com> writes:
| > >
| > > | > char fooble ( ... )
| > > | > {
| > > | >    return 'z';
| > > | > }
| > > | >
| > > | > on an x86, 'z' will be returned at the lowest 8 bits in %eax.=20
| > > | > What I
| > >
| > > | > don't know is, is the C compiler obliged to clear the=20
| upper 24=20
| > > | > bits
| > > of
| > > | > %eax, or does that onus fall on the callee?
| > > |
| > > | Yes, the callee is required to narrow <expr> in 'return=20
| <expr>;'=20
| > > | to fit that of the specified return type -- see 9.8 of Harbison=20
| > > | and Steele.
| > > |
| > ...
| > > So we don't need to worry about doing the masking on the Haskell=20
| > > side, right?
| > >
| >
| > Yes, that's been my understanding. But, as Carl Witty=20
| rightly points=20
| > out, a distinction can be made between narrowing down the=20
| result value=20
| > and the transmission of the narrowed result back to the caller.
| >
| > Carl's example doesn't fully convince me though, since the masking=20
| > done in the code for "g" is patently redundant ("f" does=20
| mask out the=20
| > upper 3 bytes of %eax upon return). However, the example=20
| given in the=20
| > original bug report can be made to emit code that doesn't=20
| mask %eax =20
| > (via "gcc-2.96 -O" on an i686-pc-linux). Another data point is that=20
| > MSVC also emits code that masks.
| >
| > So, indications are that you actually do need to mask on an=20
| x86, but=20
| > I've got no supporting documentation. If anyone is able to=20
| dig up more=20
| > info and/or know someone that could answer this one decisively, I'd=20
| > interested to hear of their findings.
| >
| > --sigbjorn
| >
| > btw, the document specifying the x86 ABI, located via
| >
| >     http://uwsg.iu.edu/hypermail/linux/kernel/0011.1/0596.html
| >
| > , doesn't cover this as far as I've been able to tell.
| >
| >
| >
| > _______________________________________________
| > Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
| > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|=20
|=20