Re: Implementing Exception Handling in a VM

Hans-Peter Diettrich wrote:


> Barry Kelly wrote:
>
> > [SEH doing two walks, cut as per anti-quoting policy :)]
>
> Why does a debugger require to walk the stack twice?
> I cannot find such a requirement in your explanation.


It's common in Windows IDEs (for example, Visual Studio or Borland
Delphi) to only pop up the debugger if the exception isn't caught deeper
in the stack. If there is only one stack walk which unwinds as it does
so, the objects etc. at the point of the exception throw will have been
destructed / finally blocks executed by the time the debugger discovers
that the exception has been unhandled. That means that extra code has
been run after the exception has been thrown, and that makes debugging
the cause of the exception more difficult, because the in-situ state has
been lost. This two-phase walk happens even if a debugger is not
attached, since a unhandled exception prompts a JIT debugger if you've
got one installed, which can do the same examination of state etc.


For more info, see probably the best reference on SEH on Windows, Matt
Pietrek's "Crash Course on the Depths of Win32™ Structured Exception
Handling":


http://www.microsoft.com/msj/0197/exception/exception.aspx


Relevant quote:


MP> When an exception occurs, the system walks the list of
MP> EXCEPTION_REGISTRATION structures until it finds a handler for the
MP> exception. Once a handler is found, the system walks the list
MP> again, up to the node that will handle the exception. During this
MP> second traversal, the system calls each handler function a second
MP> time. The key distinction is that in the second call, the value 2
MP> is set in the exception flags. This value corresponds to
MP> EH_UNWINDING. (The definition for EH_UNWINDING is in EXCEPT.INC,
MP> which is in the Visual C++ runtime library sources, but nothing
MP> equivalent appears in the Win32 SDK.)
MP> What does EH_UNWINDING mean? When an exception callback is invoked a
MP> second time (with the EH_UNWINDING flag), the operating system is
MP> giving the handler function an opportunity to do any cleanup it
MP> needs to do. What sort of cleanup? A perfect example is that of a
MP> C++ class destructor.


> There remain more aspects to be specified, for a specific SEH model:
> What does it mean that a debugger can "handle" exceptions?
> Where can operation resume, after a exception has been handled?


AFAIK, on Win32 the debugger gets first-chance notification for an
exception via a debug event (WaitForDebugEvent()). It can tell the
system to clear the exception state or to let exception handling resume
as normal (ContinueDebugEvent() with or without
DBG_EXCEPTION_NOT_HANDLED). The process is frozen while the debugger is
processing the debugger event, so it can modify EIP etc. as it desires
(SetThreadContext() takes CONTEXT* has Eip field etc. on x86). This is
what I surmise from perusal of the Win32 debugging APIs, I've never
gotten around to writing a native debugger, insert usual disclaimer,
etc.


> Can handlers be implemented for specific exceptions?
> (and possibly more)


AFAIK, SEH (as described by Matt Pietrek above) simply implies calling
the function in the _EXCEPTION_REGISTRATION_RECORD structure twice, once
for search and again for unwinding. AFAIK, the return value of the
function for the first round tells the system what to do - to resume
unhandled, or that this record does or doesn't handle the exception -
this filter logic for specific exceptions is arbitrary code. I don't
know where it puts its stack for stack overflow etc.


> This is why in .NET a distinction is made between (compiler provided)
> "filter" code, and (user provided) "handler" code.


Yes, the filter code corresponds to the first walk and the handler code
to the second walk, AFAIK.


-- Barry


--
http://barrkel.blogspot.com/

Return to the comp.compilers page.
Search the comp.compilers archives again.