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.  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.

I see a couple of options:

1. see if we can relax cygwin.dll to live with a 16k alternate stack

2. recompile every application that linked against libsigsegv to make
use of cygwin's new constants (at least those applications like m4 that
were using shared gnulib code to guess at the right stack size will now
guess correctly, hand a larger stack to libsigsegv, and libsigsegv can
then just use sigaltstack() as desired)

3. recompile libsigsegv for 32-bit to put in a hack: if the stack size
passed by the caller is < 64k but >= 16k, then fall back to the older
back-door Windows native stack overflow handling.

Option 1 is risky and might not be possible; option 2 will happen
eventually, but option 3 seems like the smoothest way to avoid breaking
things while waiting to reach the point of option 2.  Of course, if we
can get all maintainers to rebuild, then option 3 is wasted effort.

How many applications would need to be rebuilt?  I see:

diffutils [me]
m4 [me]
clisp [Ken Brown]

and nothing else mentioning libsigsegv in 32-bit setup.hints.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org