This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7] Updated: libsigsegv-2.6-1


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Reini Urban on 7/24/2009 11:54 AM:
> clisp started using libsigsegv for 2 purposes:
> 1) sigv handling to enable generational garbage collection (enabled on cygwin),
> 2) no-cost stack overflow handling (as with m4, but disabled on clisp's cygwin)
> 
> cygwin has this speciality in libsigsegv handler-win32.c:
> # undef HAVE_STACK_OVERFLOW_RECOVERY
> # define HAVE_STACK_OVERFLOW_RECOVERY 0
> And clisp checks for #if HAVE_STACK_OVERFLOW_RECOVERY

handler-win32.c is the internal implementation detail of libsigsegv.  The
line you are quoting occurs just before handler-win32.c includes
handler-unix.c for the sigsegv recovery, since handler-win32.c is already
taking care of the stack overflow recovery.  The real thing that clisp is
checking for is in sigsegv.h, which does indeed set
HAVE_STACK_OVERFLOW_RECOVERY to 1 on cygwin (thanks to handler-win32.c).

> 
> But segv handling is mandatory for decent performance and only
> stack overflow handling corrupts the cygwin stack.

It seems to me that libsigsegv is not corrupting the cygwin stack - yes,
it is using some undocumented internals (and thus is very fragile if
cygwin makes changes), but it is successfully installing an alternate
stack, and can successfully return from that alternate stack back into the
primary stack (at least, several of the tests in the libsigsegv testsuite
prove this point).

> I could be persuaded to disable stack overflow handling temp. at all
> on cygwin, but Bruno should have the last word on this. Esp. since
> Eric enabled it lately. For m4 I guess.
> But I will not disable the generational garbage collector for clisp on cygwin.

That's the whole point of my recent changes to allow libsigsegv 2.6+ plus
cygwin 1.7.0-52 or newer to do generational garbage collection without
having to bypass any cygwin internals.  In other words, we've just made
cygwin more portable this week, so that libsigsegv can get by with one
less hack: http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00092.html

> 
> Eric,
> Where is the upstream discussion happening with you and Bruno?
> On sf.net is only old libsigsegv code, and there's no public mailinglist.

I've been following up on a thread on the bug-gnulib list (since it was
the gnulib list where I first mentioned the m4 crash due to libsigsegv
interference at process shutdown):
http://lists.gnu.org/archive/html/bug-gnulib/2009-07/threads.html#00034

But we do need to repackage libsigsegv to pick up on this; the current
packaging (libsigsegv0-2.6-1) mucks unnecessarily with SEH handling even
for generational garbage collection support.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpp/vkACgkQ84KuGfSFAYC0KgCfUTb5LAFlDT2fcK7or6nFbCWN
NX8An2c7Weqc47ahJiY8YOayg1mGq2XP
=oGTm
-----END PGP SIGNATURE-----

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]