This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH] Fix Cygwin bootstrap, PR40807 and all significant FAILs on win32.
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Timothy Wall <twalljava at dev dot java dot net>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, libffi-discuss at sourceware dot org, Java Patches <java-patches at gcc dot gnu dot org>, Rainer Emrich <rainer at emrich-ebersheim dot de>
- Date: Thu, 23 Jul 2009 12:16:03 +0100
- Subject: Re: [PATCH] Fix Cygwin bootstrap, PR40807 and all significant FAILs on win32.
- References: <4A676BBB.3060104@gmail.com> <7F7052A2-9F37-4935-B8B4-2F2EE7ACED52@dev.java.net>
Timothy Wall wrote:
>
> On Jul 22, 2009, at 3:42 PM, Dave Korn wrote:
>> [ ... ] stumbled across a bigger can of worms. The code in
>> win32.S doesn't take account of numerous among the FFI_TYPE_xxx return
>> types, leading to stack-based garbage being returned, and in one place
>> mishandles the ABI convention that the callee should pop the hidden
>> pointer arg for struct return types.
>>
>
> I had noticed this too, but had convinced myself that the "unhandled
> types" would never actually be used due to the way the prep functions
> set things up (by code inspection and the fact that the tests
> corresponding to usage of those types were not failing).
I think it started happening since the fix for PR32843. I'm not even sure
if all the return types would be used, but for simplicity I went and
implemented the whole lot in a consistent and clean fashion in all the
functions. Optimising away unneeded ones is a matter for another day :)
> BTW, you can reduce the test suite execution time by commenting out all
> but one variation of the test runs in libffi.call/call.exp (the suite is
> repeated 5 times with different optimization options). You'll still
> want to run them all, but a single run will give you an overall sense of
> your FAIL status. Running tests under cygwin is really slow, and
> glacially slower if there are any failures.
It's not too bad on my machine, takes 15-25 minutes to run the whole thing,
depending on other load, but that's a handy thought, ta.
cheers,
DaveK