Re: Implementing Exception Handling in a VM

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.


This could be determined while unwinding the stack, up to the point
where application code comes into play.




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


IMO all this could be handled in the first-chance invocation of the
debugger.


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


I.e. in this case no debugger is active for a first-chance notification,
and the OS must determine whether to activate an JIT debugger for
unhandled exceptions?




> 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


Thanks :-)


In this article I noticed that it's biased on NT4, so it may be outdated
with regards to the actual behaviour of the newer Windows versions. A
new version, with notes also on the .NET SEH model, still is missing.


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


What will mean, without further background information, that nobody will
take notice of that first stack walk, besides for an debugger, which
receives the intermediate notifications.




The following questions were for the implementation of SEH in general,
not for the sake of discussing the Windows specific model.
Thanks for you detailed answers anyway :-)


DoDi

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