This is the mail archive of the cygwin-patches mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 01/04/2015 18:36, Jon TURNEY wrote:
On 01/04/2015 15:22, Corinna Vinschen wrote:On Apr 1 14:19, Jon TURNEY wrote:Add ucontext.h header, defining ucontext_t and mcontext_t types. Provide sigaction sighandlers with a ucontext_t parameter, containing stack and context information. * include/sys/ucontext.h : New header. * include/ucontext.h : Ditto. * exceptions.cc (call_signal_handler): Provide ucontext_t parameter to signal handler function.Patch is ok with a single change: Please add a "FIXME?" comment to: else RtlCaptureContext(); On second thought, calling RtlCaptureContext here is probably wrong. What we really need is the context of the thread when calling call_signal_handler I think.I had the same thought, but this is going to be quite tricky to achieve.
It would be better to call RtlCaptureContext before calling call_signal_handler. But this requires a change in how call_signal_handler is called. We should discuss this at one point, I think.
I noticed that we already prepare a context for continuing after the signal for the debugger, so perhaps this is not quite as complex as I thought and something like the attached is needed.
It's very hard to reason about if this is doing the right thing when the signal is delivered across threads, though.
Attachment:
0001-Use-the-same-continuation-context-in-a-signal-as-we-.patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |