Mail Archives: cygwin/2009/07/24/13:55:07
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
- Raw text -