Ian Lance Taylor wrote:
>> 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?
SEH is either triggered off well-defined CPU exceptions, or by a software
throw. There is no SIGALARM. You could set a timer callback and raise an
exception from within that, but the OS wraps an SEH handler around the timer
callback anyway, so it'll catch and discard the exception anyway. I don't
think there should be any fundamental problem making it work. (In fact, I
haven't even convinced myself yet that it would be impossible to fully
interwork SEH and DW2 EH.)
> 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.
Oh, right, I get you now. Yep, that's fair enough, I think that's just what
we do; dump it straight in the user's lap and tell them it's their problem.
One example I found (a slightly silly one, perhaps, but in somebody's real
code out there) was pointers to library functions that get loaded-on-demand by
being NULL to start with. When the caller catches the exception caused by
jumping to location zero, it loads up the library, finds the function address,
sets the function pointer var to the now-known value and then frobs the
thread context's EIP to point to the now-loaded function before returning.
cheers,
DaveK
