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