MIME-Version: 1.0
In-Reply-To: <20090724043005.GA10827@ednor.casa.cgf.cx>
References: <4A678AC7.7090303@x-ray.at> <4A6854F8.4060204@byu.net> 	 <20090723144038.GA11519@ednor.casa.cgf.cx> 	 <loom.20090723T145926-237@post.gmane.org> 	 <20090723171656.GA6973@ednor.casa.cgf.cx> <4A690D27.3050109@gmail.com> 	 <20090724020225.GB10306@ednor.casa.cgf.cx> 	 <4A6924E7.9030103@gmail.com> 	 <20090724043005.GA10827@ednor.casa.cgf.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@x-ray.at>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.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