Tcl Source Code

View Ticket
Login
Ticket UUID: 1910041
Title: Support of gnu x86_64-pc-mingw SEH
Type: Patch Version: None
Submitter: ktietz70 Created on: 2008-03-08 12:10:55
Subsystem: 52. Portability Support Assigned To: kennykb
Priority: 9 Immediate Severity:
Status: Closed Last Modified: 2010-12-13 16:29:41
Resolution: Duplicate Closed By: dgp
    Closed on: 2010-09-08 15:49:44
Description:
Hallo,

NightStrike and me prepared a patch for tcl to support for the gnu compiler the SEH emulation.
May you are interested in this.

Regards,
  Kai
User Comments: nijtmans added on 2010-12-13 16:29:41:

allow_comments - 0

nijtmans added on 2010-12-13 16:29:40:
Just found out that TkFinalize sometimes crashes on Win64 (compiled with mingw-w64). The cause is that here still SEH emulation was active, but it only saves and restores 32-bit pointers in stead of 64-bit. So I modified Kai's patch (Thanks!!!!) to protect the TkFinalize call in stead of the Win32-specific code.

This is an example (IMHO) where the assembler code is not meant o protect
from an OS bug, but to protect finalizing Tk when the application went in an invalid state. That's unfortunate, but a good excuse to keep it in.

Thanks, Kai. Your patch was a great help in understanding what was going on here.

dgp added on 2010-09-08 22:49:44:

allow_comments - 1

dgp added on 2010-09-08 21:26:09:
see 3059922

kennykb added on 2010-09-08 21:02:26:
Is there an actual case where the SEH stuff is needed in 64-bit Windows?

I had an earlier patch for it, that I didn't apply because it's far from obvious that it's needed.

SEH appears in the following places in the code.

(1) tclWin32Dll.c (TclWinCPUID) - Conditioned away on Win64; protects the CPUID instruction from causing an illegal operation exception on early 386/486 CPUs. (Almost certainly no longer relevant in any case.)

(2)  tclWinChan.c (Tcl_MakeFileChannel) - This one is weird, but appears to come up on WinNT and Win2k only. On those systems, if certain channel handles are duplicated, the DuplicateHandle function will succeed, but closing the duplicated handle will throw EXCEPTION_INVALID_HANDLE.  This is almost certainly a bug in a Windows device driver somewhere. I'll be happy to put in protective logic on Win64 in this spot if someone can come up with a test case that fails on some machine, somewhere.

(3) tclWinFCmd.c (DoRenameFile): On Windows NT/2k (and not on more recent versions nor on Windows CE), an attempt to rename a serial port gets a null pointer exception down inside kernel32.dll. This code is definitely a workaround for an operating system bug that was fixed years ago.

(4) tclWinFCmd.c (TclpObjDoCopyFIle): The same error, only with copying a serial port. Once again, it's an operating system bug that was fixed years ago.

So in short, all of these things appear to be in places that aren't relevant for 64-bit versions of Windows. I'll certainly bump the priority for a failing test case, but it's hard to justify the complexity of the assembly code solution if it's just to provide workarounds for operating system bugs that were fixed years ago.

dgp added on 2010-09-08 20:38:32:
Here's my attempt to update this patch
to the current 8.5.9 sources.  Needs testing.

dgp added on 2010-09-08 20:38:05:

File Added - 386004: kai-update.patch

nijtmans added on 2008-06-14 22:56:54:
Logged In: YES 
user_id=61031
Originator: NO

Had a look at the patch. I'm not an assembler expert, but
the patch only contains x64 versions of already present
x32 assembler portions. Looks good! (Although I don't have
a Win64 system around to test it) I think it should be
checked in.
I hope that one day gcc will support SEH, then this portions
of assembler will not be necessary any more.

ktietz70 added on 2008-03-08 19:10:56:

File Added - 269546: kai.patch

Attachments: