[Tcl-bugs] [ tcl-Patches-525746 ] SEH support under mingw

[<no...@so...>]

Patches item #525746, was opened at 2002-03-04 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=310894&aid=525746&group_id=10894

Category: 49. Configure and Build Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mo DeJong (mdejong)
Assigned to: Mo DeJong (mdejong)
Summary: SEH support under mingw

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Mo DeJong (mdejong)
Date: 2002-03-08 15:44

Message:
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.


----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-07 19:32

Message:
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.

----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-07 16:46

Message:
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?


----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-06 23:18

Message:
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 :(

----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-06 21:58

Message:
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?


----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-06 21:23

Message:
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.

----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-06 00:25

Message:
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

----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-06 00:02

Message:
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.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-05 16:07

Message:
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

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-05 00:20

Message:
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

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-05 00:18

Message:
Logged In: YES 
user_id=7549

nevermind.  found it.  __attribute__((naked))

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-04 23:53

Message:
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?

----------------------------------------------------------------------

Comment By: Mo DeJong (mdejong)
Date: 2002-03-04 23:16

Message:
Logged In: YES 
user_id=90858

Ok, uploading a new patch to fix that.

----------------------------------------------------------------------

Comment By: David Gravereaux (davygrvy)
Date: 2002-03-04 21:52

Message:
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;
}


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=310894&aid=525746&group_id=10894