From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 7413 invoked from network); 29 Oct 2020 14:02:40 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 29 Oct 2020 14:02:40 -0000
Received: (qmail 19788 invoked by uid 550); 29 Oct 2020 14:02:38 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 19762 invoked from network); 29 Oct 2020 14:02:37 -0000
Date: Thu, 29 Oct 2020 17:02:26 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: musl@lists.openwall.com
In-Reply-To: <alpine.LNX.2.20.13.2010291649450.2454@monopod.intra.ispras.ru>
Message-ID: <alpine.LNX.2.20.13.2010291701040.2454@monopod.intra.ispras.ru>
References: <20201029063448.GK534@brightrain.aerifal.cx> <b215b5cf68dfefc5b35e41900b5bafef@ispras.ru> <20201029133839.GL534@brightrain.aerifal.cx> <alpine.LNX.2.20.13.2010291649450.2454@monopod.intra.ispras.ru>
User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [musl] More thoughts on wrapping signal handling



On Thu, 29 Oct 2020, Alexander Monakov wrote:

> On Thu, 29 Oct 2020, Rich Felker wrote:
> 
> > Yes, I kinda hand-waved over this with the word "call", which I
> > thought about annotating with (*). In the case of SA_ONSTACK you need
> > a primitive to "call on new stack", and while the ucontext is mostly
> > not meaningful/inspectable to the signal handler (because it's
> > interrupting libc code), the saved signal mask is. You can have the
> > caller restore it (in place of SYS_[rt_]sigreturn), but the natural
> > common solution to all of these needs is having a sort of makecontext.
> 
> Alternatively you could re-raise the signal to have the kernel re-deliver
> it with the correctly regenerated ucontext (and on the right stack)?
> Would that be undesirable for some reason?

Ah, because there's no way to propagate siginfo struct. Sorry :)

Alexander