Dave Korn <dave.korn.cyg...@googlemail.com> writes: > 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.
It would be fine to do this on a target-by-target basis. I would regard it as a bug fix. > Also, windows doesn't have signal handlers. Except on Cygwin, which would > have to deal with this in its own way. Does Windows have any asynchronous signalling mechanism which can trigger an SEH-style exception? Or does SEH only trigger on a certain class of instructions? >> 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! Right, which is why I said that from gcc's point of view we have to say that EXCEPTION_CONTINUE_EXCEPTION is simply undefined. I don't see how we can make any meaningful statements about it. In particular, I don't see how we can document cases where it may be used. Even a volatile global won't work in all cases, unless we are prepared to somehow back up execution before the point of loading the address of the global. Ian
