This is the mail archive of the insight@sourceware.org mailing list for the Insight 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: MinGW setjmp SEGV


  I don't understand the need for it yet, though; can you enlarge on the
problem or point me at a tcl.sourceforge bugzilla report?

See: http://sources.redhat.com/ml/insight/2004-q1/msg00021.html


The problem is that the assembly code is broken (reentrancy aside). It saves the value of %fs:0 (the pointer to the exception handler I think, but I'm not totally clear on this), but the restore code is broken and just writes random data. The next function in Insight to dereference this pointer is in setjmp so we see the crash there.

This patch would
affect cygwin as well as mingw, since it also defines HAVE_NO_SEH; AFAIUI,
the macro means 'have no seh support in the compiler' rather than 'have no
seh in the target OS', but cygwin (apparently) is happy enough using 'doze
SEH, and I don't understand the comment about "Unlike Borland and Microsoft
we don't .... pushing registration records onto the runtime stack." Yet
the EXCEPTION_REGISTRATION variable "registration" is on the stack and
appears to be linked into the 'doze SEH chain in pretty much the usual
fashion. I'm sure this is just my lack of comprehension.

As I understand it, the assembler code is supposed to simulate the '__try {} __except {}' stuff in compilers which do not support that. I don't know what compilers do support it though. Cygwin's 'gcc -mno-cygwin' does not.


I don't understand the comment either. Obviously the GCC compiled Insight/TCL does not use this stuff automatically, but the msvcrt.dll does use it - I can see it in the disassembly. I would imagine that any other MSVC compiled DLLs also use it. Perhaps it makes more sense along with the rest of the updated TCL, but as far as I can tell it is local to this one file and only used three times (once here).

  OTOH this patch would seem to address my concerns about the reentrancy
problems of using static _ESP and _EBP variables.

I don't know about that, I just cut a pasted the code from sourceforge.


Should or shouldn't the same changes be made to the exception handling in
tclWinFCmd.c and tclWinChan.c as well?

There is other similar code in sourceforge, but not all of it is relevant so I just took enough to fix the problem at hand. See http://cvs.sourceforge.net/viewcvs.py/tcl/tcl/win/tclWin32Dll.c?rev=1.46&view=auto


I have submitted this to help, but you should be aware that I am not certain whether any ST copyright stuff may be used in Insight (particularly the TCL parts), although we do have an assignment for GDB. That's part of the reason why I have not submitted the full set of patches to make Insight go. The TCL stuff from sourceforge is obviously not a problem, at least not if you get it from there yourself.

Andrew Stubbs


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