DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 52ECs7J31338024 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 52ECs7J31338024 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=ni8crW7j X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 96A953857724 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1741956846; bh=twlnfDMrW2D4FT4EauNedIRlV1b07to9gu7E+4qBU6E=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=ni8crW7jbbwale5s1gbi1ZLqOT0d/wygiFd1sa5YvO+paDbljDHTRC4eeucGAbsEM YnkhFODfjlVHFEtt1PM/8soQf+kB8R7Xs1AtO0k/E7c9w0NrAdOLR7ppQN+RbBNz0M 5YsaPfc7Qspb60rBhcMnQPDvwKsMbVL/kS/wJVHk= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 107723857710 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 107723857710 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741956765; cv=none; b=e4LGhVW5rH0gdG28FmN0UMmQAv87++rPAVodtVdBBYYE0RRfa+FaXYQ1aKPD1jO31r6SLVJbpuXQm9v7p+Y2Q2gQ6uEX2Eh743CmCD2cg4Pe7zGBGTM3eH3oE3YIe5PJ8JOG7m+2+ncmaF8BsGTp5ivHUY+Y0Td5SKKIb3G5x7Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1741956765; c=relaxed/simple; bh=ntmCQuMsNVnv6peEsGi09fvvtqSuukStTcxLBHcHHBI=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=Irhd0VINJS1UXirSwYTuzuwgYkP5uij0KqO6A45EejFDUsiOg5GhVKXsXLOPE0RQtXZRoCkASTq48C8iy8srPZhBwjzpiHI2Km+M6q0NcKF/sLuoS1YcbSwwIJERWyG8G4GZwWQCmE6zZp+Z1Bf78+9/KtK9SRpesO4D35TGL/s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 107723857710 Date: Fri, 14 Mar 2025 21:52:42 +0900 To: cygwin AT cygwin DOT com Subject: Re: cygwin 3.6.0: No signals received after swapcontext() is used Message-Id: <20250314215242.8ef1214b77ccc472139b3a3a@nifty.ne.jp> In-Reply-To: References: <20250313204252 DOT e340f0de50838f161b0e8323 AT nifty DOT ne DOT jp> <20250313213148 DOT 6c2cb65f5e692005f28d3d2c AT nifty DOT ne DOT jp> <20250314081236 DOT bbdb1da7d746745925cdc752 AT nifty DOT ne DOT jp> <20250314125632 DOT dc61b5b087eb43d67228cc92 AT nifty DOT ne DOT jp> <20250314203548 DOT 878211c61777a8d99b7de7ea AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Fri, 14 Mar 2025 13:19:28 +0100 Corinna Vinschen wrote: > On Mar 14 20:35, Takashi Yano via Cygwin wrote: > > On Fri, 14 Mar 2025 11:01:25 +0100 > > Corinna Vinschen wrote: > > > I don't think so. I was mulling in circles over this tonight > > > (don't ask me how I slept!) and came to the same conclusion. > > > But here's the problem: > > > > > > I'm simply not 100% sure. > > > > > > What concerns me is that stackptr points beyond stack if the stack > > > is full (i.e., sigdelayed + return address). > > > > > > That was what happened before I applied a942476236b5: stackptr was > > > incremented until it pointed at _cygtls::initialized, and eventually it > > > overwrote it. Fortunately, that stopped further incrementing due to the > > > isinitialized() test. > > > > > > So, if there *is* a twisted situation which results in pushing another > > > return address onto the stack, a stack size of 2 would again result in > > > initialized being overwritten. So I wonder if we should keep kind of > > > an airbag for an unusual situation. Plus trying to keep stackptr inside > > > stack even if it's full. So that stackptr never grows into initialized: > > > > > > #define TLS_STACK_SIZE 5 > > > > > > and > > > > > > void push (__tlsstack_t addr) > > > { > > > if (stackptr < (__tlsstack_t *) &initialized) > > > *stackptr++ = (__tlsstack_t) addr; > > > } > > > > > > What do you think? > > > > Yeah. We do not have to minimize the stack space at the cost of > > taking risks. > > > > One more thing. I am also concerned that pop() lacks a guard. > > If pop() calls when stack is empty, then push() destroys the > > stackptr pointer value. > > Good point. I attach a new proposal. It also doesn't check against > &initialized (becasue that doesn't avoid an overflow into initialized, > but against the last slot of the stack. This also moves pop into > the C++ code and drops its assembler counterpart. > > Ok? LGTM. Thanks! -- Takashi Yano -- 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