Re: generating functions and eh region

[Ian Lance Taylor <iant at google dot com>]

Dave Korn <dave.korn.cygwin@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