Ian Lance Taylor wrote:
> No fundamental difficulty that I know of. Lots of tedious work for
> every backend setting RTX_FRAME_RELATED_P and adding
> REG_FRAME_RELATED_EXPR notes to the manually constructed epilogue insns.
>
> And, in fact, I was wrong in saying that exception could only occur
> during specific types of instructions. As far as I can see, with SEH
> exceptions can occur at any time: consider signal handlers.
I think we're only proposing to add SEH support for platforms where the OS
supports it. Would it be an impediment to a patch if it only fixed -fa-u-t
for platforms where we needed epilogue handling to work correctly, and left it
up to other target maintainers to decide for themselves if they needed this
functionality on their platforms? From one point of view it might seem a
partial transition, but from another point of view it's adding an enhanced
functionality to some backends that need it. We could always have a target
macro SUPPORTS_ASYNCH_EPILOGUE_EXCEPTIONS that indicates the appropriate
annotations will be added.
Also, windows doesn't have signal handlers. Except on Cygwin, which would
have to deal with this in its own way.
> How does the exception handler know how to "reset the variable in the
> outer scope?" With gcc, that variable may simultaneously live in
> multiple different registers and could even live in two different memory
> locations (e.g., a global variable which was loaded into a register and
> then spilled to the stack during reload).
The example was a bit strained, but applications do exist for
EXCEPTION_CONTINUE_EXECUTION. The general problem of how to meaningfully
resume execution is left to the application programmer to solve. They might
make a variable into a volatile global or adjust the thread context structure.
Yes, that's hacky. This is windows we're talking about!
cheers,
DaveK
