From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101269 invoked by alias); 18 Jul 2015 20:11:10 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 101258 invoked by uid 89); 18 Jul 2015 20:11:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 18 Jul 2015 20:11:08 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 258B5A8057B; Sat, 18 Jul 2015 22:11:06 +0200 (CEST) Date: Sat, 18 Jul 2015 20:11:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2 Message-ID: <20150718201106.GE3864@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <55AA9882.1030407@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LSp5EJdfMPwZcMS1" Content-Disposition: inline In-Reply-To: <55AA9882.1030407@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00100.txt.bz2 --LSp5EJdfMPwZcMS1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3113 On Jul 18 12:18, Eric Blake wrote: > On 07/17/2015 05:22 PM, Eric Blake (cygwin) wrote: > > A new release of libsigsegv, 2.10-2, will soon be available for download > > from your favorite mirror. On 32-bit cygwin, this leaves 2.10-1 as > > previous; on 64-bit cygwin, it is a new port of the package, made > > possible for the first time by new sigaltstack() code in cygwin 2.1.0. >=20 > Oddly enough, this new library actually causes a regression in 32-bit m4 > - with libsigsegv-2.10-1, I get stack overflow handling, but with -2, > attempting to register the handler fails and m4 ends up dumping core on > stack overflow. But it's not quite libsigsegv's fault. Oh well. I thought libsigsegv allocates the alternate stack. If the application has to do that by itself anyway, I wonder why use libsigsegv. > m4 was > originally creating an alternate stack of 16k in size, based on a pure > guess that it would be large enough (since the headers didn't declare > any constant otherwise); but cygwin's sigaltstack() requires an > alternate stack of 64k or larger. No, 32K (MINSIGSTKSZ) is sufficient. > I see a couple of options: >=20 > 1. see if we can relax cygwin.dll to live with a 16k alternate stack Right now, the bookkeeping at the top of the alternate stack is required only for a handful of saved registers and what the altstack_wrapper function needs. All in all that amounts to 464 bytes on 64 bit and 336 bytes on 32 bit, so there's still plenty of stack, even with a 2K stack, as is the definition of MINSIGSTKSZ on x86{_64} Linux. The reason I raised MINSIGSTKSZ to 32K was that sigaltstack is pretty new, so I was unsure if there might be a good reason to copy the _cygtls area over to the alternate stack for some reason. If so, we would have needed another 12K of the stack for bookkeeping. MINSIGSTKSZ is defined like this in SUSv4: "The value MINSIGSTKSZ is defined to be the minimum stack size for a signal handler. In computing an alternate stack size, a program should add that amount to its stack requirements to allow for the system implementation overhead." So in fact, MINSIGSTKSZ is supposed to only amount for the very minimum anyway. That would make 16K for MINSIGSTKSZ much more feasible *iff* we'd need the _cygtls copy. The longer I play with this, the less it seems likely we really need the _cygtls copy. In fact, it even seems to be a bad idea to do that because it requires to change the stack addresses in the TEB, which would break in an awful way as soon as the handler calls siglongjmp or (the very new) setcontext or swapcontext. OTOH, calling certain Cygwin functions might require lots of stack. E.g. open/read/write/close requires more than 2K stack, so MINSIGSTKSZ shouldn't be too small. So, what about MINSIGSTKSZ =3D=3D 8192 and SIGSTKSZ =3D=3D 32768? Or MINSIGSTKSZ =3D=3D 16384 and SIGSTKSZ =3D=3D 65536? That could go into Cygwin 2.2.0 which I could release next week. Thanks, Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --LSp5EJdfMPwZcMS1 Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVqrLaAAoJEPU2Bp2uRE+gvLMP/2oblHR8iI5bpowDj1LNjRtJ ZDkPFWmtEZZtKa3RnnmlSYCUUjhOo28SX0ofdwq2N+Qg/gu1L1vjQtt2+BSs3Tp3 5hJpAg3Nxflhif4+KMbh5iASy/u4qrMTqWGgfg3E9FZRESOLUDxKsn/Prsmb8boI uHhZaF+9isSI/vwuQ/+ekFQkKM/gFrPup8+0rRioVV83bBhDE+h28JhgOTPSqH20 tdjyJ7vIwF61/nuK6OzL/mBCU2yAbnLkzjflTTVAsmOif5slH/VDWUhLiVCZ5q1T rwcAxWpEF3zL522ry6wqa//tv1ImohWiObacJ4qzz14gmj7eKuo9tvNJj6XVSxnc 6wIEA/J10w6IOyOqjm6l33FIZjWEAcdydzQtLA+Qqu65oycS2Y8aPBOPlUaSsY8C odN2Ly0+9mWqvUcSX99L8OSPGTQU2cE1mdR0qfqVxIiMwp8OOP2Lr/j0lpf/LD9t kQXtqEGMtsenL7TTVHrL5ToLoEryGqjRsvwXA9kYbuCR/9PGVzyPpOc4PwYIL0fX ZGa+AykjFUUAb6Dw5qQOrMFq3uCyKPMtmFB1ospYFrJsZm5wd6AqhlmyZ1tVD7hj xmrXQSeYw0pQLlk+Pav34lAzdNJ5me/Lcg91oL2XjZNAL3lqL8oy7ncBGeq2BfMw Dg60iyO2VNoh+ReOPwi3 =LHiB -----END PGP SIGNATURE----- --LSp5EJdfMPwZcMS1--