On Fri, 14 Mar 2025 08:18:41 +0900
Takashi Yano wrote:
> On Fri, 14 Mar 2025 08:12:36 +0900
> Takashi Yano wrote:
> > On Thu, 13 Mar 2025 23:46:49 +0100
> > Corinna Vinschen wrote:
> > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote:
> > > > On Mar 13 21:31, Takashi Yano via Cygwin wrote:
> > > > > What about following patch instead of your sigdelayed patch?
> > > > > [...]
> > > > > @@ -1834,6 +1841,26 @@ _cygtls::call_signal_handler ()
> > > > > signal handler. */
> > > > > thisfunc (thissig, &thissi, thiscontext);
> > > > >
> > > > > + lock ();
> > > > > + if (stackptr == ptr)
> > > > > + push (retaddr1);
> > > > > + else if (stackptr == ptr + 1)
> > > > > + {
> > > > > + DWORD64 retaddr3 = pop();
> > > > > + push (retaddr1);
> > > > > + push (retaddr3);
> > > > > + }
> > > > > + else if (stackptr == ptr - 1)
> > > > > + {
> > > > > + if (retaddr2)
> > > > > + push (retaddr2);
> > > > > + else
> > > > > + stackptr++;
> > > > > + }
> > > > > + else
> > > > > + api_fatal ("Signal stack corrupted?.");
> > > > > + unlock ();
> > > > > +
> > > >
> > > > This... looks confusing and desperately needs comments (or at least
> > > > I need comments).
> > > >
> > > > stackptr == ptr + 1 occurs if another signal arrived while the handler
> > > > was running, but isn't there a chance that sigdelayed has been pushed
> > > > as well, i.e., stackptr == ptr + 2?
> > > >
> > > > I have no idea how the stackptr == ptr - 1 situation is supposed to
> > > > happen, though. `else stackptr++;' looks weird. If you don't push a
> > > > known address, what do you expect retaddr() pointing to, afterwards?
> > >
> > > I have a slighty changed version. This one treats anything other
> > > than 0, 1 or 2 new addresses on the stack as bug. I really made
> > > an effort trying to come up with a situation where the signal
> > > stack underflows, but I just couldn't. If I'm missing something,
> > > please explain how this may happen.
> > >
> > > Apart from that, I attached my patch proposal.
> >
> > I think the following is the right thing. This version pulls return
> > addresses completely (not only one) before calling signal handler.
>
> Sorry, I forgot to mention why.
> In the next case, the previous patch consumes stack one.
>
> User code
> signal handler 1
> signal ahndler 2
> longjmp
> User code
No, I was wrong. The _cygtls::stack is pulled every time
when call_signal_handler() is called. So, the _cygtls::stack
is always empty when signal handler is called.
--
Takashi Yano <takashi.y...@nifty.ne.jp>
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
