Re: [ANNOUNCEMENT] Updated for 32-bit, new for 64-bit: libsigsegv-2.10-2

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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.
> 
> 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:
> 
> 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 == 8192 and SIGSTKSZ == 32768?

Or MINSIGSTKSZ == 16384 and SIGSTKSZ == 65536?

That could go into Cygwin 2.2.0 which I could release next week.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpdbSo9lwdz0.pgp
Description: PGP signature