This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi 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] win64 support for libffi (2/2)


Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>> Andrew Haley wrote:
>>>> NightStrike wrote:
>>>>> When are you planning to do this?  I want to time some other changes
>>>>> in my personal repo with this change.
>>>> Today, if I have time, otherwise next week.
>>>   I have an outstanding patch to libffi/src/x86/win32.S
>>>
>>> http://gcc.gnu.org/ml/java-patches/2009-q2/msg00084.html
>> Please commit this.
> 
>   Two things:
> 
> a)  Tests not quite finished yet, but fixed lots of FAILs.  Only other change:
> 
> -FAIL: Thread_Wait_2 -findirect-dispatch output - source compiled test
> -FAIL: Thread_Wait_Interrupt output - source compiled test
> +FAIL: Thread_Interrupt -findirect-dispatch output - source compiled test
> +FAIL: Thread_Wait_2 output - source compiled test
> +FAIL: Thread_Wait_Interrupt -O3 -findirect-dispatch output - source compiled test
> 
> ... which I think is probably noise.  The Process_N tests all hang, I think
> there is a bug somewhere in the underlying cygwin pthread support (there is
> some ever-present noise in libstdc++ tests relating to mutexes as well, which
> supports this theory).

OK.

> b)  Just the libffi, or both parts?  I haven't tested the libjava
> runtimeInitialized change separately.

Doesn't this change fix the early failure in throwing an exception?
If not, please don't check it in.

>>>   There is currently one difference between our win32.S and upstream libffi
>>> win32.S, where upstream adds a new entrypoint, _ffi_closure_STDCALL.
>>>
>>>   Would it help if I added that function and EH annotations for it to my patch?
>> Yes.  Consider it pre-approved.
> 
>   Thanks, under way.  I think I have to duplicate out the function tail-end
> code that the current upstream version shares with _ffi_closure_SYSV (from
> .Lcls_return_result on) because as far as I've been able to figure out so far,
> we can't represent shared/overlapping ranges like this in FDEs.  It's not a
> huge amount of code, but if you do happen to know a way to do it, please send
> me a pointer, or confirm that it's still OK with the code duplication.

Duplication is fine.

Andrew.


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