On 09/07/2010 17:51, Christopher Faylor wrote: > Someone may be looking into this but if this is adding complication to the > signal handler it is going to take some real convincing that it should go > into the DLL.
:) Fortunately, it doesn't have to do that. All the magic takes place in libgcc's last-chance unwind fallback hook(*). The only impact on the DLL, in the design I've been experimenting with, is that we need to build it with EH unwind tables, add a cygwin_internal method to return a pointer to the EH data, and export a couple of entrypoints that libgcc needs to be able to look up. There are no changes in any of the signal/exception code paths, or at any rate I didn't yet find any need to change anything (I didn't finish getting it working before I put it aside though, so it's conceivable-but-low-probability that something might turn up). > Dave, this is something that you should be talking about early rather than > springing it as a patch in cygwin-patches. Sure, I was going to get a working PoC first because I wanted to convince myself it was possible, but no reason not to discuss it right now. Luckily I think there's very little to discuss. (I'll report what the EH data does to the DLL size when I've got the code up and running again, but since everyone's been waiting long enough, I guess the first thing I should do is get out a more vanilla-flavoured 4.5.0 release.) cheers, DaveK -- (*) - MD_FALLBACK_FRAME_STATE_FOR -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple