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


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. ?If we decide to change anything in SEH handler, which we do
>>>>>from time to time, this code is likely to break. ?We 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. ?I 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? ?It'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. ?For 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. ?From 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. ?It's entirely possible that I missed something in 2),
> of course, but it would be nice to know if I am. ?Turning 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 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

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

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


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