X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=iCcfaB7QJCoGnkHuIjiedpULycuLbVL1zzbc/g+rLf3ND/5avvIUQ
	iZgeeTwxW9q02PQIVGyYcAPEdqP/TRrEm2KR9/hFMkcPs2ZN5gXGDdY/skfGqwg1
	OcoPxzjpjeQonvJKap1e8hWUz7FUSgrp9BtDSsTWIx2MMpxNXST+wY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=MwdokgF/GJ+3+FLXzIgNnCndGew=; b=J0A1vyuApRSLfW4LkM+NMgeoogDE
	CKGsPnQ75QfDSe4UDWjaJOXqxDkhw9rvTKr5Kwuc8k0DoV4t44es97ePlMvanlQo
	n3gMa6NwMY57qXe6vbv5iDtrQksb9INkxpMxu2EaLqnlGGmFagHsj6oTeBR/Gx0G
	ldH0/OgYOwMVDEg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=laid
X-HELO:	mout.kundenserver.de
Date:	Sat, 2 Feb 2019 18:05:08 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com, Sam Habiel <sam DOT habiel AT gmail DOT com>
Subject:	Re: 32 bit vs 64 bit Cygwin, followup
Message-ID:	<20190202170508.GB3532@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, Sam Habiel <sam DOT habiel AT gmail DOT com>
References:	<CABHT96207sag6z7LMMDiBQciu-B3o7zFoOkYLw3OOSi_S=Kckg AT mail DOT gmail DOT com> <db507cae25f6f4b20af039bf3931e727d9614f61 DOT camel AT redhat DOT com> <CABHT963855jsHu0r=1f0dHye9k+uGb21EYkSj1SS+06V0bhsjg AT mail DOT gmail DOT com> <20181129085816 DOT GV30649 AT calimero DOT vinschen DOT de> <CABHT962ok6x121SezynVto2k1DoQ6T6Wj3J+Nq9O+AQs+uNeRQ AT mail DOT gmail DOT com> <20181129163327 DOT GD30649 AT calimero DOT vinschen DOT de> <CABHT961E1J3z_QjDr_PQu6gerUqsNnHN6NMBSBNas=4mbcNBiQ AT mail DOT gmail DOT com> <CABHT961Uinr8yQNkPqmUzg5amsRCppBK1DYcZaptz-iczb17Og AT mail DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<CABHT961Uinr8yQNkPqmUzg5amsRCppBK1DYcZaptz-iczb17Og@mail.gmail.com>
User-Agent:	Mutt/1.10.1 (2018-07-13)

--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb  2 09:42, Sam Habiel wrote:
> On Sat, Feb 2, 2019 at 9:39 AM Sam Habiel <sam DOT habiel AT gmail DOT com> wrote:
> >
> > On Thu, Nov 29, 2018 at 11:33 AM Corinna Vinschen
> > <corinna-cygwin AT cygwin DOT com> wrote:
> > >[...]
> > > One way is to create a SYSV wrapper for each C function called from
> > > assembler.  Assuming this simple scenario:
> > > [...]
> > I and a colleague started the work to migrate the Linux x64 version to
> > Cygwin. The results have been very promising; but I think we found a
> > bug in gcc when dealing with va_start in sysv_abi compiled code. I
> > have a simple test case. Can somebody confirm? It works fine without
> > the attribute on PrintFloats.
> >
> > /* va_start example */
> > #include <stdio.h>      /* printf */
> > #include <stdarg.h>     /* va_list, va_start, va_arg, va_end */
> >
> > void __attribute__ ((sysv_abi)) PrintFloats (int n, ...)
> > {
> >   int i;
> >   double val;
> >   printf ("Printing floats:");
> >   va_list vl;
> >   va_start(vl,n);
> >   for (i=3D0;i<n;i++)
> >   {
> >     val=3Dva_arg(vl,double);
> >     printf (" [%.2f]",val);
> >   }
> >   va_end(vl);
> >   printf ("\n");
> > }
> >
> > int main ()
> > {
> >   PrintFloats (3,3.14159,2.71828,1.41421);
> >   return 0;
> > }
>=20
> Sorry. Should say what the error is:
>=20
> Hp AT memphis ~/fis-gtm/build
> $ gdb a.exe
> [...]
> (gdb) r
> Starting program: /home/Hp/fis-gtm/build/a.exe
> [New Thread 11672.0xdd0]
> [New Thread 11672.0x1230]
> [New Thread 11672.0x20ac]
> [New Thread 11672.0x43f4]
>=20
> Thread 1 "a" hit Breakpoint 1, main () at test.c:23
> 23        PrintFloats (3,3.14159,2.71828,1.41421);
> (gdb) s
> PrintFloats (n=3D1) at test.c:6
> 6       {
> (gdb) s
> 9         printf ("Printing floats:");
> (gdb) s
> 11        va_start(vl,n);
> (gdb) s
> 12        for (i=3D0;i<n;i++)
> (gdb) p vl
> $1 =3D (va_list) 0x3000000008 <error: Cannot access memory at address
> 0x3000000008>
> (gdb) s
> [New Thread 11672.0x3f9c]
> 14          val=3Dva_arg(vl,double);
> (gdb) s
>=20
> Thread 1 "a" received signal SIGSEGV, Segmentation fault.
> 0x000000010040112f in PrintFloats (n=3D3) at test.c:14
>=20
> PS: Running this outside GDB causes Cygwin x64 to hang--and I don't
> know how to make it unhang.

That's not GCC fault.  You're running varargs, written for the standard
stack layout of the MSABI target from a function with a stack laid out
in SYSV ABI.  That can't work.

If you *have to* use varargs from SYSV ABI functions, you have to define
your own version of them.

But there's another problem with no easy hackaround, the hang you're
observing after the SEGV.

Keep in mind that *Windows* runs the exception handling in the first
place, not Cygwin.  Cygwin only installs a structured exception handler,
but that requires that windows can *find* the exception handler.

To do this, Windows needs to unwind the stack until it finds the
exception handler.  However, you're running a function using the SYSV
stack layout the Windows stack unwinder doesn't know about.  As a
result, this goes nowhere.  The stack unwinder runs wild or, if you're
lucky, just stops in the outermost structured exception handler or some
vectored exception handler.

I'm not sure there is a solution to that.  What you could try is to
install a structured exception handler inside the SYSV call.  You may
have to do this inside each and every SYSV function which *may* crash to
keep the Windows stack unwinder having to unwind to the calling function
at all.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxVzcQACgkQ9TYGna5E
T6DhLQ//VHKN0gadCWamJJPQd9sX2q9Q1nMUiW1wjkqkvS9C38L2qFLgHmVdDdRT
OZKa7sQqsbw3mvsLbcpC5qjTN4DuqZ/tt2NcSjoDtrqntYOWJj5op0Ozgnbe8j9m
hf9AQcHCh1Vvqqgk9LQ1DTjUQ+ltDjK4gRnmQh8kcRagw1RyeeCDpEPfI95c8hHk
IKnmRfuP10mJhovkoeszxMBN/S6jGX6F5zQZAJHTJhuq5P9iOc0BXm8dkCvolf5b
JtkIEa7K4974Xy8p64suz76L226Hl4fC947cgGcp3qQtsRAqlcDbf5B0c+ImgPwW
eWq//Rm8SnMLRJqM+pJfsLX0fxWvY9LZsRY793VK6HKL/ByDpHqS/hyXUkuyRJS+
9gfFDDOdeVrKnVep+Xed68g2tbESTsqI8/KN5nWM75+q6vrfO4NJPeaQs+PnE2a1
fAZ3tZli1OQa82dDqdyXGAMQ2CWl7qDN1/MWWc/WmLubx2D1Z+eJ3VPN8nqTsLjh
vGwVxf1sUHKmmS4Dm9tUKOeosnFHpVN1NTkc6hQDpZRMFxwLeivxWIH4aXt4CeCf
B6CLupSyZf0hkkn2NkcHIRFAgMaArwli6jNiCp4krffaBY7RlhuQN4v7HOUhcnRb
cSr/H9FeVgINn4sI60dAdP/j8v3q1+t+XG+nuOc0lLJOdXbinJ4=
=D98/
-----END PGP SIGNATURE-----

--jI8keyz6grp/JLjh--

- Raw text -