Tcl Source Code

Existing releases of mingw either fail to
support SEH or "fake it" so that things
compile. This is going to be a problem
for Tcl since code in win/tclWin32Dll.c,
win/tclWinChan.c, and win/tclWinFCmd.c
depends on SEH. This patch ident will be
used to collect patches related to SEH
support before merging.

File Added - 40566: new_handler.c

Logged In: YES 
user_id=90858

After some more thinking about SEH I found that the
current approach is not thread safe and needs to be fixed
so that it uses the stack instead of global vars. The tricky
part is that what we need to do is use the thread local
fs:0 register to lookup the original exception handler
info when our exception handler gets called. The
new_handler.c file I just added is a short example
of this new approach in action. I will create a larger
patch for Tcl and check it into the CVS.

Logged In: YES 
user_id=90858

I tested out gcc_asm.patch3 and it seems to be working
just fine. Checked in to CVS on 2002-03-14.

File Deleted - 19369: 



File Added - 19384: gcc_seh_asm.patch3

File Deleted - 19051: 



File Added - 19369: gcc_seh_asm.patch2

Logged In: YES 
user_id=90858

Here is a new patch to implement SEH in gcc. It should
be ready to go, just needs a little testing.

Logged In: YES 
user_id=90858

I just got a report back from a kind soul named Stephen
Trier. He tested the patch out on NT and it did not change
any test results. I have to assume that use of a continue
handler was simply a mistake. I am checking this no_continue
patch in.

File Deleted - 19124: 



File Added - 19305: no_continue_handler.patch

Logged In: YES 
user_id=90858

I am leaving saturday and will be gone for a couple of
weeks. It would be nice if we could get this and the
mingw asm thing worked out before then.

Logged In: YES 
user_id=7549

I'm a bit busy this week.  I'll give it a shot this weekend.

File Added - 19124: no_continue_handler.patch

Logged In: YES 
user_id=90858

I thought about it, and I just can't come up with
any reason this exception handler should continue
instead of handling the exception. Bug 466102
shows what would happen if something does go
wrong in the MoveFile or CopyFile API, the whole
process locks up because the fault and the handler
run in an infinite loop. This code dates back
to Tcl 8.0 so I can't find any record of why it
was it was added or what it should do. Could you
grab this no_continue_handler.patch, apply it,
and rerun the test cases under NT to see if there
are any differences? The tests don't work properly
under Win98 right now, but that is going to have
to be dealt with in another bug report.

Logged In: YES 
user_id=7549

Lucky you.  You've got time to play around with this while 
I'm nose deep in the daily grind.

If MoveFileA and EXCEPTION_CONTINUE_EXECUTION don't work 
together, then I think you've found a deep bug.  No 
infinite loop found on NT with your example (it needed a 
missing '}' though).  Note that Tcl might be changing its 
error mode with SetErrorMode(), and that causes exceptions 
to behave a bit different on some operations.  I don't know 
the exact details though.

Let me know if I can assist.  You've got it all done, and 
now I'm just an observer :)

BTW, _except_handler3 is found in msvcrt.dll.  here's the 
proof:

D:\>dumpbin /exports c:\winnt\system32\msvcrt.dll | 
find "_except_handler"
        205   CC 0001F17E _except_handler2
        206   CD 0000DB11 _except_handler3

I'm not saying we should use it, but if we do need to 
interface with it, it's there.

Logged In: YES 
user_id=90858

I did some testing of the asm SEH impl and found that
it was going into an infinate loop when running test
winFCmd-1.7.

At first, I thought I coded something up wrong, but
then I found that the VC++ compiled executable is
also going into an infinate loop in this same
place. I am seeing these results on a Win98 box.

Here is a small example:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int main() {
    __try {
      MoveFileA(NULL, "C:\\A.TXT");
    __except (EXCEPTION_CONTINUE_EXECUTION) {}
}

This loops forever because MoveFileA is generating
a SIGSEGV over and over again. I just don't understand
why these two calls in tclWinFCmd.c are coded to
restart the faulting instruction and why others
don't seem to be running into this infinate loop
problem in winFCmd.test.

File Added - 19051: gcc_seh_asm.patch

File Deleted - 19049:

File Added - 19049: gcc_seh_asm.patch

Logged In: YES 
user_id=90858

I just attached the patch gcc_seh_asm.patch which should
get Tcl to compile with gcc. This patch is going to need
testing, but I think it will work.

As far as _except_handler3 goes, I was under the impression
that it was not defined in msvcrt.dll. This nm output of
msvcrt.lib seems to support that view.

msvcrt.lib:build/intel/dll_obj/wcrtexew.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/wcrtexe.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/ehvecdtr.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/ehveccvb.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/ehvecctr.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/crtexew.obj:         U
__except_handler3
msvcrt.lib:build/intel/dll_obj/crtexe.obj:         U
__except_handler3

Instead VC++ includes this handler in the statically
linked runtime library. The inline ASM handlers I wrote
would not invoke cleanup handlers farther up on the
stack, but I don't think this will be a problem in
the guarded calls to alloca() or CloseHandle(). The
other two handlers just restart the faulting instruction.
To be honest, I am not sure why they do that, it seems
unsafe because a NULL pointer deref could send the
application into an infinate loop.

Logged In: YES 
user_id=7549

we might be able to use the builtin one from msvcrt.dll 
called _except_handler3.

Or maybe use our own.  The logic would be easier.

I'll play some more with listing outputs from VC++, and get 
a better grip on how it's innards are working.

As long as it works, and cleans up after itself, I don't 
think it would matter which method is used.  BTW, I didn't 
know you could specify labels with inline asm with gcc :)  
inline asm in VC++, that isn't allowed.

File Added - 19015: handler.c

Logged In: YES 
user_id=90858

I did some more hacking and came up with handler.c.
It will create a SEH handler that does a jmp back
into the original function. The only way I could
see to implement this was to save the ESP and EBP
pointers before entering the guard block and then
restoring them after returning from the handler.
Does this seem like a reasonable thing to be doing?

Logged In: YES 
user_id=7549

none at all.  I like it.

moseh.c rocks, too.  I was almost that far, but have to 
stay focused on the day gig :(

File Added - 18948: seh_return.patch

Logged In: YES 
user_id=90858

I did some reading up on control flow statements in
try blocks here:

http://www.gamedev.net/reference/programming/features/sehbasics/

Since return statements in try blocks are bad news,
I whipped up a new patch to get rid of them and use
symbolic names instead of hard coded values. Any
objection to checking this patch in?

Logged In: YES 
user_id=90858

"Small comment.  returns from a __try block  aren't good."

Well, I was just poking around in tclWinFCmd.c when
I noticed this:

__try {
    if ((*tclWinProcs->moveFileProc)(nativeSrc, nativeDst)
!= FALSE) {
    return TCL_OK;
}
    }

Should we move that return statement out of the __try
block? Something like the following perhaps?

int retval = -1;
__try {
    if (func())
        retval = TCL_OK;
} __except(...) {}

if (retval != -1)
    return retval;


This also shows up in tclWin32Dll.c:

 __try {
alloca(TCL_WIN_STACK_THRESHOLD);
return 1;
 } __except (...) {}


Should both of these be changed? I think that adding
the asm statements will be easier if we make this
change.

I also noticed that we should be using
EXCEPTION_CONTINUE_EXECUTION instead of -1 in
tclWinFCmd.c.

Logged In: YES 
user_id=90858

Here is another cool link for general 32 bit x86
asm stuff.

http://www.drpaulcarter.com/pcasm/pcasm-book.pdf

File Added - 18863: moseh.c

Logged In: YES 
user_id=90858

You are right, that last URL is a really great ref.
I took some time today to convert one of the examples
over to AT&T syntax and compiles with Mingw 1.1. I
will attach it so you can have a look.

Logged In: YES 
user_id=7549

I'm just logging this great resource.

http://www.microsoft.com/msj/defaultframe.asp?
page=/msj/0197/exception/exception.htm&nav=/msj/0197/newnav.
htm

Logged In: YES 
user_id=7549

I spoke too soon.  The docs say it only works on the ARM or 
AVR ports.

testSEH.c:21: warning: `naked' attribute directive ignored

Logged In: YES 
user_id=7549

nevermind.  found it.  __attribute__((naked))

Logged In: YES 
user_id=7549

small Q.  How can one add an attribute to a function so 
that the prologue and epilogue is stripped?

I saw -mschedule-prologue and -mno-epilogue as switches, 
but I'd rather, if possible, do it like how __stdcall and 
__cdecl are used for attributes.  Is there such a thing for 
stripping?

File Deleted - 18807: 



File Added - 18817: seh.patch

Logged In: YES 
user_id=90858

Ok, uploading a new patch to fix that.

Logged In: YES 
user_id=7549

Looks good.  Small comment.  returns from a __try block 
aren't good.  This is more strict:

int main(...)
{
    int a, b = 0;
    __try {
a = 666 / b;
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {
return 1;
    }
    return 0;
}

File Added - 18807: seh.patch