Re: Implementing Exception Handling in a VM

Barry Kelly wrote:


> Doing it manually in the interpreter loop: the way you do it depends on
> what you want, but it basically involves walking up the call stack. If
> you want a debugger to pick up on unhandled exceptions, you've should
> probably do two walks: once to look for handlers until you find one, and
> then walk the stack again and free up all the stack frames including all
> locals (important if you've got C++ destructor-like semantics on any of
> your types) and execute 'finally' blocks (unwinding). Once your done
> with that and you've gotten the handler from the first walk, you simply
> set up your machine to execute inside it. If you don't need the debugger
> support, you can just do one walk that does both.


Why does a debugger require to walk the stack twice?
I cannot find such a requirement in your explanation.


IMO a pre-search for an exception handler is required only, when the
language allows to resume operation in an different place, outside the
exception handler that caught the exception. I understood this behaviour
as something like "repair and resume", perhaps related to Basic
Resume[same/next/linenumber]-style exception handling.


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?
Can handlers be implemented for specific exceptions?
(and possibly more)


Only if a double stack-walk is required, handlers for specific
exceptions require more considerations. Then the decision cannot be made
in user code, because the stack may not already have been unwound. This
is why in .NET a distinction is made between (compiler provided)
"filter" code, and (user provided) "handler" code.


This is why I ask for a more detailed discussion, whether multiple stack
walks are a requirement, and the role of debugging in this decision.


[...]
> The two-walk approach described above is basically the way that both
> ..NET and Win32 SEH work, AFAIK, in order to get good debugger support.
> If it unwound while searching for a handler, you wouldn't be able to
> inspect the function context at the point where an unhandled exception
> was thrown.


I cannot see how the operation of an debugger is related to a known
location of the exception handler code, determined by a first walk
through the stack?


DoDi

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