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


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:
>>>>On Thu, Jul 23, 2009 at 04:35:12PM +0000, Eric Blake wrote:
>>>>>>I really don't like the games this package plays.  I'm halfway tempted
>>>>>>to just make it nonfunctional in Cygwin.
>>>>>It works just fine, especially now that it only uses SEH for stack
>>>>>overflow detection instead of assuming that all SEH faults imply
>>>>>SIGSEGV.
>>>>
>>>>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.

And, for the record, I was wrong in my assertion that libsigsegv wasn't
doing anything special with the stack.  Eric showed where it was.

cgf

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