public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: TEST RELEASE: Cygwin 2.1.0-0.4
       [not found] <20150705213417.GH2918@calimero.vinschen.de>
@ 2015-07-08 19:39 ` Warren Young
  2015-07-08 20:12   ` Ken Brown
                     ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Warren Young @ 2015-07-08 19:39 UTC (permalink / raw)
  To: The Cygwin Mailing List

On Jul 5, 2015, at 3:34 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> ...RLIMIT_STACK...RLIM_INFINITY.

This should fix the Emacs crash you reference later in this message without rebuilding Emacs, right?

I’m not an Emacs user, as you know, but is there an STC for the Emacsizens to try on their systems?

> - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE,
>  MINSIGSTKSZ, SIGSTKSZ.

Since these were entirely missing before, this can’t be tested without rebuilding software, right?  When rebuilt, existing Cygwin packages may discover the new APIs via autoconf or similar.

A search for "sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks.

Of those projects that I didn’t recognize as a receiver of these API calls, I didn’t recognize any as existing Cygwin user-space packages.

So, is it simply the case that the only people who will care to test this are those who already know they’re trying to call this, and need it to work?

> - New API: sethostname.

For what it’s worth, that gave a pretty similar result set: lots of OSes and low-level infrastructure, few user-space packages.

> - Enable non-SA_RESTART behaviour on threads other than main thread.
>  Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00260.html

Nice fix for an obscure problem.

And thanks for providing references, so that those like me who didn’t pay attention to the original thread can catch up and see why we care about these fixes. :)
--
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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-08 19:39 ` TEST RELEASE: Cygwin 2.1.0-0.4 Warren Young
@ 2015-07-08 20:12   ` Ken Brown
  2015-07-09  9:46   ` Corinna Vinschen
  2015-07-14 22:03   ` Eric Blake
  2 siblings, 0 replies; 10+ messages in thread
From: Ken Brown @ 2015-07-08 20:12 UTC (permalink / raw)
  To: cygwin

On 7/8/2015 3:39 PM, Warren Young wrote:
> On Jul 5, 2015, at 3:34 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
>> ...RLIMIT_STACK...RLIM_INFINITY.
>
> This should fix the Emacs crash you reference later in this message without rebuilding Emacs, right?
>
> I’m not an Emacs user, as you know, but is there an STC for the Emacsizens to try on their systems?

There's no crash in the current Emacs release.  The crashes we were 
discussing were in my build of the current Emacs development trunk, 
which can use an alternate stack in order to recover from stack 
overflow.  This has no impact on users of the current Emacs release.

Ken

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-08 19:39 ` TEST RELEASE: Cygwin 2.1.0-0.4 Warren Young
  2015-07-08 20:12   ` Ken Brown
@ 2015-07-09  9:46   ` Corinna Vinschen
  2015-07-14 22:03   ` Eric Blake
  2 siblings, 0 replies; 10+ messages in thread
From: Corinna Vinschen @ 2015-07-09  9:46 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On Jul  8 13:39, Warren Young wrote:
> On Jul 5, 2015, at 3:34 PM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > ...RLIMIT_STACK...RLIM_INFINITY.
> 
> This should fix the Emacs crash you reference later in this message
> without rebuilding Emacs, right?
> 
> I’m not an Emacs user, as you know, but is there an STC for the
> Emacsizens to try on their systems?

As Ken wrote.

> > - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE,
> >  MINSIGSTKSZ, SIGSTKSZ.
> 
> Since these were entirely missing before, this can’t be tested without
> rebuilding software, right?  When rebuilt, existing Cygwin packages
> may discover the new APIs via autoconf or similar.
> [...]
> So, is it simply the case that the only people who will care to test
> this are those who already know they’re trying to call this, and need
> it to work?

Kind of, yes.  The relevant snippet from the announcements:

2.1.0-0.1 - 2.1.0-0.3:

  This test release is mostly for interested *developers*.  

2.1.0-0.4 - 2.1.0-0.5:

  While the changes are still mostly interesting for developers, the
  under-the-hood changes will potentially impact existing applications.

But note the latter.  These under-the-hood changes which affect existing
applications are:

- Changes to how getrlimit(RLIMIT_STACK) works and how pthread stacks
  are set up now.  The general effect is that pthreads will have bigger
  default stacks now, 2 rather than 1 Meg, unless the application
  developer or maintainer handled the pthread stacksizes explicitely.

- Child stack allocation after fork has been rearranged and partially
  rewritten.  This is new code at the core of how fork works.  This,
  of course, affects all existing applications using the fork call.

> > - New API: sethostname.
> 
> For what it’s worth, that gave a pretty similar result set: lots of
> OSes and low-level infrastructure, few user-space packages.

Yes, but it was easy to implemement and another API which may help
building packages without having to tweak them for Cygwin:
https://cygwin.com/ml/cygwin-patches/2015-q2/msg00076.html

> 
> > - Enable non-SA_RESTART behaviour on threads other than main thread.
> >  Addresses: https://cygwin.com/ml/cygwin/2015-06/msg00260.html
> 
> Nice fix for an obscure problem.
> 
> And thanks for providing references, so that those like me who didn’t
> pay attention to the original thread can catch up and see why we care
> about these fixes. :)

No worries,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-08 19:39 ` TEST RELEASE: Cygwin 2.1.0-0.4 Warren Young
  2015-07-08 20:12   ` Ken Brown
  2015-07-09  9:46   ` Corinna Vinschen
@ 2015-07-14 22:03   ` Eric Blake
  2015-07-15  2:08     ` Ken Brown
  2 siblings, 1 reply; 10+ messages in thread
From: Eric Blake @ 2015-07-14 22:03 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

On 07/08/2015 01:39 PM, Warren Young wrote:

>> - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE,
>>  MINSIGSTKSZ, SIGSTKSZ.
> 
> Since these were entirely missing before, this can’t be tested without rebuilding software, right?  When rebuilt, existing Cygwin packages may discover the new APIs via autoconf or similar.
> 
> A search for "sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks.
> 

libsigsegv is a cygwin package (currently 32-bit only) that has
configure checks to use sigaltstack if present; I have not yet tested if
it can be configured to work with the new API, but hope to do so in the
near future.  In fact, if sigaltstack works, it may finally be possible
to port libsigsegv to 64-bit cygwin (the reason the current package is
not ported to 64-bit is that libsigsegv is relying on raw assembly and
Windows native calls to emulate the lack of sigaltstack; but if
sigaltstack works, then we don't need to port the 64-bit counterpart for
the 32-bit specific hacks).

I'm not the cygwin packager for libsigsegv, but am one of the upstream
contributors, and so this thread has piqued my interest.  Sadly, I'm a
bit late to the testing because I was on vacation last month, and am now
trying to catch up with several things that happened during my
(much-needed) downtime, such as a new upstream release of coreutils.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-14 22:03   ` Eric Blake
@ 2015-07-15  2:08     ` Ken Brown
  2015-07-15  7:51       ` Corinna Vinschen
  0 siblings, 1 reply; 10+ messages in thread
From: Ken Brown @ 2015-07-15  2:08 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]

On 7/14/2015 6:03 PM, Eric Blake wrote:
> On 07/08/2015 01:39 PM, Warren Young wrote:
>
>>> - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE,
>>>   MINSIGSTKSZ, SIGSTKSZ.
>>
>> Since these were entirely missing before, this can’t be tested without rebuilding software, right?  When rebuilt, existing Cygwin packages may discover the new APIs via autoconf or similar.
>>
>> A search for "sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks.
>>
>
> libsigsegv is a cygwin package (currently 32-bit only) that has
> configure checks to use sigaltstack if present; I have not yet tested if
> it can be configured to work with the new API, but hope to do so in the
> near future.  In fact, if sigaltstack works, it may finally be possible
> to port libsigsegv to 64-bit cygwin (the reason the current package is
> not ported to 64-bit is that libsigsegv is relying on raw assembly and
> Windows native calls to emulate the lack of sigaltstack; but if
> sigaltstack works, then we don't need to port the 64-bit counterpart for
> the 32-bit specific hacks).

I just did a quick test, and it looks promising.  I removed all Cygwin-specific 
code from configure.ac and Makefile.am (see attached patch), and it then built 
on 64-bit Cygwin.  Here's the result of 'make check':

Entering directory 
'/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
Test passed.
PASS: sigsegv1.exe
Test passed.
PASS: sigsegv2.exe
Doing SIGSEGV pass 1.
Stack overflow 1 caught.
Doing SIGSEGV pass 2.
Stack overflow 2 caught.
Test passed.
PASS: sigsegv3.exe
SKIP: stackoverflow1.exe
SKIP: stackoverflow2.exe
======================
All 3 tests passed
(2 tests were not run)
======================
[...]
Please send the following summary line via email to the main author
Bruno Haible <bruno@clisp.org> for inclusion into the list of
successfully tested platforms (see PORTING file).

libsigsegv: x86_64-unknown-cygwin | yes | no | 2.10

> I'm not the cygwin packager for libsigsegv,

No one is; it's orphaned.

> but am one of the upstream
> contributors, and so this thread has piqued my interest.

So it seems that you would be the obvious person to maintain it, if you have the 
time.  If you don't have the time, I'd be willing to ITA it just to get it into 
the 64-bit distro.  But in that case I'd appreciate it if you would review my 
build after I send the ITA, since you actually know something about libsigsegv, 
and I don't.

> Sadly, I'm a
> bit late to the testing because I was on vacation last month, and am now
> trying to catch up with several things that happened during my
> (much-needed) downtime, such as a new upstream release of coreutils.

Ken

[-- Attachment #2: libsigsegv-2.10-1.src.patch --]
[-- Type: text/plain, Size: 2385 bytes --]

--- origsrc/libsigsegv-2.10/configure.ac	2015-07-14 20:32:45.036228200 -0400
+++ src/libsigsegv-2.10/configure.ac	2015-07-14 20:42:36.489057300 -0400
@@ -522,19 +522,6 @@ case "$host_os" in
     FAULT_CONTEXT_INCLUDE='#include <windows.h>'
     CFG_FAULT=fault-win32.h # nonexistent, just a dummy
     ;;
-  cygwin*)
-    FAULT_CONTEXT='struct _CONTEXT'
-    # CONTEXT is defined in <windows.h>, but cygwin programs should not
-    # normally inspect the contents of CONTEXT, and the outright inclusion
-    # of <windows.h> pollutes the namespace.
-    FAULT_CONTEXT_INCLUDE='struct _CONTEXT;'
-    # Cygwin 1.7 uses fault-posix.h. Cygwin 1.5.x needs a hacky workaround.
-    if test -z "$CFG_FAULT"; then
-      CFG_FAULT=fault-cygwin-old.h
-      AC_DEFINE([OLD_CYGWIN_WORKAROUND], [1],
-        [Define to 1 on Cygwin versions older than 1.7.])
-    fi
-    ;;
 esac
 if test -n "$CFG_FAULT"; then
   sv_cv_have_sigsegv_recovery=yes
@@ -861,7 +848,7 @@ AC_CACHE_CHECK([if the system supports c
     sv_cv_have_stack_overflow_recovery=yes
   else
     case "$host_os" in
-      mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
+      mingw*) sv_cv_have_stack_overflow_recovery=yes ;;
       *)
         if test "$CFG_LEAVE" != 'leave-none.c'; then
           if test "$sv_cv_sigaltstack" != no; then
@@ -930,7 +917,7 @@ dnl Requires AC_CANONICAL_HOST, CFG_HAND
 dnl HAVE_SIGSEGV_RECOVERY, HAVE_STACK_OVERFLOW_RECOVERY.
 
 case "$host_os" in
-  mingw* | cygwin*) CFG_HANDLER=handler-win32.c ;;
+  mingw*) CFG_HANDLER=handler-win32.c ;;
   *)
     if test -z "$CFG_HANDLER"; then
       if test $sv_cv_have_sigsegv_recovery = no \
@@ -961,7 +948,6 @@ dnl should make the system call fail wit
 dnl the signal handler.
 dnl It is necessary on Cygwin: otherwise the cygwin1 test fails.
 case "$host_os" in
-  cygwin*) enable_EFAULT=yes ;;
   *)       enable_EFAULT=no ;;
 esac
 if test $enable_EFAULT = yes; then
--- origsrc/libsigsegv-2.10/tests/Makefile.am	2010-10-24 13:25:15.000000000 -0400
+++ src/libsigsegv-2.10/tests/Makefile.am	2015-07-14 21:37:25.864937900 -0400
@@ -29,11 +29,6 @@ DEFS = @DEFS@
 LDADD = ../src/libsigsegv.la
 noinst_PROGRAMS = sigsegv1 sigsegv2 sigsegv3 stackoverflow1 stackoverflow2
 
-if CYGWIN
-TESTS += cygwin1
-noinst_PROGRAMS += cygwin1
-endif
-
 if ENABLE_EFAULT
 TESTS += efault1 efault2 efault3
 noinst_PROGRAMS += efault1 efault2 efault3

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-15  2:08     ` Ken Brown
@ 2015-07-15  7:51       ` Corinna Vinschen
  2015-07-15 12:44         ` Corinna Vinschen
  0 siblings, 1 reply; 10+ messages in thread
From: Corinna Vinschen @ 2015-07-15  7:51 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

Hi guys,

On Jul 14 22:07, Ken Brown wrote:
> On 7/14/2015 6:03 PM, Eric Blake wrote:
> >On 07/08/2015 01:39 PM, Warren Young wrote:
> >>A search for "sigaltstack” on code.openhub.net found only 95 projects with this string in their source code, almost entirely consisting of *receivers* of that call, such as NetBSD, glibc, and a bunch of Linux forks.
> >
> >libsigsegv is a cygwin package (currently 32-bit only) that has
> >configure checks to use sigaltstack if present; I have not yet tested if
> >it can be configured to work with the new API, but hope to do so in the
> >near future.  In fact, if sigaltstack works, it may finally be possible
> >to port libsigsegv to 64-bit cygwin (the reason the current package is
> >not ported to 64-bit is that libsigsegv is relying on raw assembly and
> >Windows native calls to emulate the lack of sigaltstack; but if
> >sigaltstack works, then we don't need to port the 64-bit counterpart for
> >the 32-bit specific hacks).
> 
> I just did a quick test, and it looks promising.  I removed all
> Cygwin-specific code from configure.ac and Makefile.am (see attached patch),
> and it then built on 64-bit Cygwin.  Here's the result of 'make check':
> 
> Entering directory
> '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
> Test passed.
> PASS: sigsegv1.exe
> Test passed.
> PASS: sigsegv2.exe
> Doing SIGSEGV pass 1.
> Stack overflow 1 caught.
> Doing SIGSEGV pass 2.
> Stack overflow 2 caught.
> Test passed.
> PASS: sigsegv3.exe
> SKIP: stackoverflow1.exe
> SKIP: stackoverflow2.exe

Any idea why these two tests have been skipped?  That means the
HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed.  You removed cygwin
from the explicit

  mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;

which is the right thing to do, but that means CFG_LEAVE has been
set to leave-none.c, apparently.

I haven't much time to look into that right now, but will later today if
you don't beat me to it.

> ======================
> All 3 tests passed
> (2 tests were not run)
> ======================
> [...]
> Please send the following summary line via email to the main author
> Bruno Haible <bruno@clisp.org> for inclusion into the list of
> successfully tested platforms (see PORTING file).
> 
> libsigsegv: x86_64-unknown-cygwin | yes | no | 2.10
> 
> >I'm not the cygwin packager for libsigsegv,
> 
> No one is; it's orphaned.
> 
> >but am one of the upstream
> >contributors, and so this thread has piqued my interest.
> 
> So it seems that you would be the obvious person to maintain it, if you have
> the time.  If you don't have the time, I'd be willing to ITA it just to get
> it into the 64-bit distro.  But in that case I'd appreciate it if you would
> review my build after I send the ITA, since you actually know something
> about libsigsegv, and I don't.

Thanks a lot, this is most helpful.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-15  7:51       ` Corinna Vinschen
@ 2015-07-15 12:44         ` Corinna Vinschen
  2015-07-15 14:24           ` Ken Brown
  0 siblings, 1 reply; 10+ messages in thread
From: Corinna Vinschen @ 2015-07-15 12:44 UTC (permalink / raw)
  To: cygwin


[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]

On Jul 15 09:51, Corinna Vinschen wrote:
> Hi guys,
> 
> On Jul 14 22:07, Ken Brown wrote:
> > Entering directory
> > '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
> > Test passed.
> > PASS: sigsegv1.exe
> > Test passed.
> > PASS: sigsegv2.exe
> > Doing SIGSEGV pass 1.
> > Stack overflow 1 caught.
> > Doing SIGSEGV pass 2.
> > Stack overflow 2 caught.
> > Test passed.
> > PASS: sigsegv3.exe
> > SKIP: stackoverflow1.exe
> > SKIP: stackoverflow2.exe
> 
> Any idea why these two tests have been skipped?  That means the
> HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed.  You removed cygwin
> from the explicit
> 
>   mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
> 
> which is the right thing to do, but that means CFG_LEAVE has been
> set to leave-none.c, apparently.
> 
> I haven't much time to look into that right now, but will later today if
> you don't beat me to it.

Got it.  What's needed is a Cygwin-specific fault-*.h file which exposes
how to fetch the stack pointer register from mcontext_t.  As you can see
from the plethora of fault-*.h files in the src subdir, this is highly
system-specific anyway.

Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0,
with all tests running and passing on i686 and x86_64.  No other patch
is requied.

So, who of you is going to maintain it?


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #1.2: libsigsegv.cygport --]
[-- Type: text/plain, Size: 871 bytes --]

NAME="libsigsegv"
VERSION="2.10"
RELEASE=2
CATEGORY=Libs
SUMMARY="Handling page faults in user mode"
DESCRIPTION="Library for handling page faults in user mode. A page fault occurs
when a program tries to access to a region of memory that is currently not
available. Mainly required to build clisp from source."
HOMEPAGE="http://libsigsegv.sourceforge.net/"
# SRC_URI="ftp://www.gnu.ftp.uni-erlangen.de/pub/gnu/${PN}/${PN}-${PV}.tar.gz"
# SRC_URI="http://puzzle.dl.sourceforge.net/sourceforge/${PN}/${PN}-${PV}.tar.bz2"
# SRC_URI="ftp://ftp.gnu.org/pub/gnu/${PN}/${PN}-${PV}.tar.gz"
SRC_URI="http://ftpmirror.gnu.org/${PN}/${PN}-${PV}.tar.gz"

DLLREV=2
MAKEOPTS="-j1"
CYGCONF_ARGS="--enable-shared" 

PKG_NAMES="${PN} ${PN}${DLLREV}"
PKG_CONTENTS[0]="--exclude=usr/bin/cygsigsegv-${DLLREV}.dll usr"
PKG_CONTENTS[1]="usr/bin/cygsigsegv-${DLLREV}.dll"

[-- Attachment #1.3: libsigsegv-2.10-2.src.patch --]
[-- Type: text/plain, Size: 3126 bytes --]

--- origsrc/libsigsegv-2.10/configure.ac	2011-04-03 17:30:16.000000000 +0200
+++ src/libsigsegv-2.10/configure.ac	2015-07-15 14:30:22.264452393 +0200
@@ -419,6 +419,9 @@ if test -z "$CFG_FAULT" && test "$sv_cv_
               ;;
           esac
           ;;
+	cygwin*)
+	   CFG_FAULT=fault-cygwin-i386.h
+	   ;;
         *)
           CFG_FAULT=fault-posix-ucontext.h
           ;;
@@ -522,16 +525,6 @@ case "$host_os" in
     FAULT_CONTEXT_INCLUDE='#include <windows.h>'
     CFG_FAULT=fault-win32.h # nonexistent, just a dummy
     ;;
-  cygwin*)
-    FAULT_CONTEXT='CONTEXT'
-    FAULT_CONTEXT_INCLUDE='#include <windows.h>'
-    # Cygwin 1.7 uses fault-posix.h. Cygwin 1.5.x needs a hacky workaround.
-    if test -z "$CFG_FAULT"; then
-      CFG_FAULT=fault-cygwin-old.h
-      AC_DEFINE([OLD_CYGWIN_WORKAROUND], [1],
-        [Define to 1 on Cygwin versions older than 1.7.])
-    fi
-    ;;
 esac
 if test -n "$CFG_FAULT"; then
   sv_cv_have_sigsegv_recovery=yes
@@ -858,7 +851,7 @@ AC_CACHE_CHECK([if the system supports c
     sv_cv_have_stack_overflow_recovery=yes
   else
     case "$host_os" in
-      mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
+      mingw*) sv_cv_have_stack_overflow_recovery=yes ;;
       *)
         if test "$CFG_LEAVE" != 'leave-none.c'; then
           if test "$sv_cv_sigaltstack" != no; then
@@ -927,7 +920,7 @@ dnl Requires AC_CANONICAL_HOST, CFG_HAND
 dnl HAVE_SIGSEGV_RECOVERY, HAVE_STACK_OVERFLOW_RECOVERY.
 
 case "$host_os" in
-  mingw* | cygwin*) CFG_HANDLER=handler-win32.c ;;
+  mingw*) CFG_HANDLER=handler-win32.c ;;
   *)
     if test -z "$CFG_HANDLER"; then
       if test $sv_cv_have_sigsegv_recovery = no \
--- origsrc/libsigsegv-2.10/src/fault-cygwin-i386.h	1970-01-01 01:00:00.000000000 +0100
+++ src/libsigsegv-2.10/src/fault-cygwin-i386.h	2015-07-15 14:30:47.562341412 +0200
@@ -0,0 +1,33 @@
+/* Fault handler information.  Cygwin/i386 and Cygwin/x86_64 version.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#include "fault-posix-ucontext.h"
+
+#if defined __x86_64__
+/* 64 bit registers */
+
+/* See winsup/cygwin/include/cygwin/signal.h */
+
+# define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext.rsp
+
+#else
+/* 32 bit registers */
+
+/* See winsup/cygwin/include/cygwin/signal.h */
+
+# define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext.esp
+
+#endif

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-15 12:44         ` Corinna Vinschen
@ 2015-07-15 14:24           ` Ken Brown
  2015-07-15 15:08             ` Eric Blake
  0 siblings, 1 reply; 10+ messages in thread
From: Ken Brown @ 2015-07-15 14:24 UTC (permalink / raw)
  To: cygwin

On 7/15/2015 8:44 AM, Corinna Vinschen wrote:
> On Jul 15 09:51, Corinna Vinschen wrote:
>> Hi guys,
>>
>> On Jul 14 22:07, Ken Brown wrote:
>>> Entering directory
>>> '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
>>> Test passed.
>>> PASS: sigsegv1.exe
>>> Test passed.
>>> PASS: sigsegv2.exe
>>> Doing SIGSEGV pass 1.
>>> Stack overflow 1 caught.
>>> Doing SIGSEGV pass 2.
>>> Stack overflow 2 caught.
>>> Test passed.
>>> PASS: sigsegv3.exe
>>> SKIP: stackoverflow1.exe
>>> SKIP: stackoverflow2.exe
>>
>> Any idea why these two tests have been skipped?  That means the
>> HAVE_STACK_OVERFLOW_RECOVERY autoconf test failed.  You removed cygwin
>> from the explicit
>>
>>    mingw* | cygwin*) sv_cv_have_stack_overflow_recovery=yes ;;
>>
>> which is the right thing to do, but that means CFG_LEAVE has been
>> set to leave-none.c, apparently.
>>
>> I haven't much time to look into that right now, but will later today if
>> you don't beat me to it.
>
> Got it.  What's needed is a Cygwin-specific fault-*.h file which exposes
> how to fetch the stack pointer register from mcontext_t.  As you can see
> from the plethora of fault-*.h files in the src subdir, this is highly
> system-specific anyway.
>
> Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0,
> with all tests running and passing on i686 and x86_64.  No other patch
> is requied.

Great!  Thanks.

> So, who of you is going to maintain it?

I'll defer to Eric, but if he doesn't want it then I'll take it.

Ken

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-15 14:24           ` Ken Brown
@ 2015-07-15 15:08             ` Eric Blake
  2015-07-15 19:19               ` Corinna Vinschen
  0 siblings, 1 reply; 10+ messages in thread
From: Eric Blake @ 2015-07-15 15:08 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On 07/15/2015 08:24 AM, Ken Brown wrote:
>> Got it.  What's needed is a Cygwin-specific fault-*.h file which exposes
>> how to fetch the stack pointer register from mcontext_t.  As you can see
>> from the plethora of fault-*.h files in the src subdir, this is highly
>> system-specific anyway.
>>
>> Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0,
>> with all tests running and passing on i686 and x86_64.  No other patch
>> is requied.

Awesome!  Makes my work easier.

> 
> Great!  Thanks.
> 
>> So, who of you is going to maintain it?
> 
> I'll defer to Eric, but if he doesn't want it then I'll take it.

I'll take it. Expect a package up later this week, as well as a rebuilt
64-bit m4 that uses it.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: TEST RELEASE: Cygwin 2.1.0-0.4
  2015-07-15 15:08             ` Eric Blake
@ 2015-07-15 19:19               ` Corinna Vinschen
  0 siblings, 0 replies; 10+ messages in thread
From: Corinna Vinschen @ 2015-07-15 19:19 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Jul 15 09:08, Eric Blake wrote:
> On 07/15/2015 08:24 AM, Ken Brown wrote:
> >> Got it.  What's needed is a Cygwin-specific fault-*.h file which exposes
> >> how to fetch the stack pointer register from mcontext_t.  As you can see
> >> from the plethora of fault-*.h files in the src subdir, this is highly
> >> system-specific anyway.
> >>
> >> Here's the set of files you need to rebuild libsigsegv for Cygwin 2.1.0,
> >> with all tests running and passing on i686 and x86_64.  No other patch
> >> is requied.
> 
> Awesome!  Makes my work easier.
> 
> > 
> > Great!  Thanks.
> > 
> >> So, who of you is going to maintain it?
> > 
> > I'll defer to Eric, but if he doesn't want it then I'll take it.
> 
> I'll take it. Expect a package up later this week, as well as a rebuilt
> 64-bit m4 that uses it.

Sounds good, thanks!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-07-15 19:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20150705213417.GH2918@calimero.vinschen.de>
2015-07-08 19:39 ` TEST RELEASE: Cygwin 2.1.0-0.4 Warren Young
2015-07-08 20:12   ` Ken Brown
2015-07-09  9:46   ` Corinna Vinschen
2015-07-14 22:03   ` Eric Blake
2015-07-15  2:08     ` Ken Brown
2015-07-15  7:51       ` Corinna Vinschen
2015-07-15 12:44         ` Corinna Vinschen
2015-07-15 14:24           ` Ken Brown
2015-07-15 15:08             ` Eric Blake
2015-07-15 19:19               ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).