X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <20090724043005.GA10827@ednor.casa.cgf.cx>
References: <4A678AC7 DOT 7090303 AT x-ray DOT at> <4A6854F8 DOT 4060204 AT byu DOT net> 	 <20090723144038 DOT GA11519 AT ednor DOT casa DOT cgf DOT cx> 	 <loom DOT 20090723T145926-237 AT post DOT gmane DOT org> 	 <20090723171656 DOT GA6973 AT ednor DOT casa DOT cgf DOT cx> <4A690D27 DOT 3050109 AT gmail DOT com> 	 <20090724020225 DOT GB10306 AT ednor DOT casa DOT cgf DOT cx> 	 <4A6924E7 DOT 9030103 AT gmail DOT com> 	 <20090724043005 DOT GA10827 AT ednor DOT casa DOT cgf DOT cx>
Date: Fri, 24 Jul 2009 19:54:50 +0200
Message-ID: <6910a60907241054h6bebc6eo279180a0a9fd21b@mail.gmail.com>
Subject: Re: [1.7] Updated: libsigsegv-2.6-1
From: Reini Urban <rurban AT x-ray DOT at>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

2009/7/24 Christopher Faylor:
> On Fri, Jul 24, 2009 at 04:05:11AM +0100, Dave Korn wrote:
>>Christopher Faylor wrote:
>>>On Fri, Jul 24, 2009 at 02:23:51AM +0100, Dave Korn wrote:
>>>>Christopher Faylor wrote:
>>>>>The point is that this is using an undocumented "interface" into
>>>>>Cygwin. =A0If we decide to change anything in SEH handler, which we do
>>>>>from time to time, this code is likely to break. =A0We are not likely =
to
>>>>>keep libsigsegv in mind if we make future changes to the exception
>>>>>handler.
>>>>
>>>>Well, this line of argument also leads to the suggestion that we should
>>>>define a nice stable interface for it to use. =A0I haven't researched it
>>>>in depth but if, as it appears, this is a real library used by real
>>>>Linux apps to do a real job, and it is our goal to make those apps
>>>>"just recompile and work" on Cygwin as they do on Linux, then we should
>>>>give serious consideration to supporting libsigsegv and making what it
>>>>wants to do possible for it.
>>>>
>>>>cheers,
>>>
>>>There isn't any actionable thing that I can respond to in the above
>>>other than to point out that it seems like seem like you weren't
>>>reading the discussion very carefully.
>>
>>Well, there isn't any actionable thing that I can respond to in the
>>above other than to point out that I actually /was/ reading the
>>discussion carefully, which is precisely *why* I made that suggestion.
>>
>>Perhaps we should both elucidate our statements? =A0It's so much easier
>>than playing guessing games.
>
> Eric already suggested what the "stable interface" would be and I
> already pointed out that you could probably just use a similar technique
> to what is being done now while still using Cygwin's signal handling
> code without any fragile hooks into the SEH. =A0For some reason, you
> snipped both of those observations from your response.
>
> Let me add a new data point: I'll implement sigaltstack after 1.7.1 is
> released. =A0From reading libsigsegv's configure, it doesn't look like it
> will just automatically use it, however.
>
> In the meantime, I'd suggest either 1) for now, not building packages
> with libsigsegv on Cygwin or 2) trying what I suggested for dealing with
> stack overflow. =A0It's entirely possible that I missed something in 2),
> of course, but it would be nice to know if I am. =A0Turning off the
> special windows handler would be an interesting thing to do, anyway,
> because it would help show if just implementing sigaltstack would solve
> every problem for Cygwin.

Having sigaltstack would be great!

clisp started using libsigsegv for 2 purposes:
1) sigv handling to enable generational garbage collection (enabled on cygw=
in),
2) no-cost stack overflow handling (as with m4, but disabled on clisp's cyg=
win)

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

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

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 cygw=
in.

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.
--=20
Reini Urban
http://phpwiki.org/           http://murbreak.at/

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