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=NtMYbFQ/892vxC3y8yhFGhOIcU4BvM+lAV21voJioQfx144tqItqa MxLhLVUM8iqfgqq7l9lPPshKxVVlLsb3WMg47ZCN4ZsrJVy5JsnEabW4QHfZPpwa 1Zr2+nz6AVS+Z2YQF8J46PxjGyyYKZoEw2i0rVtuIDWc5DmkMmVR6Y= 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=Kkvs/XMJPeH3cYJcWcG9hJtQdYg=; b=fs8qBBeT195Ni6YAXjkR60SxJtUy 3v204cAd+7e7GXQKB2QPlUKM5u4j/296dsUDHZQ4h7X3oLqHpWsr0PQbl/guU+YY wHeP/RPPIg6HKmJwA89rBxDIVg4jT5B04e0esv38d9gCnaIF4v9qNJm0eBNwuwo4 CbinsGrE7Robxqo= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Date: Tue, 21 Oct 2014 13:17:24 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Threads Message-ID: <20141021111724.GA12476@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <54450835 DOT 3050602 AT cornell DOT edu> <20141020164324 DOT GA32374 AT calimero DOT vinschen DOT de> <20141020190350 DOT GB32374 AT calimero DOT vinschen DOT de> <54456964 DOT 4090007 AT cornell DOT edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <54456964.4090007@cornell.edu> User-Agent: Mutt/1.5.23 (2014-03-12) --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Oct 20 15:58, Ken Brown wrote: > On 10/20/2014 3:03 PM, Corinna Vinschen wrote: > >One of the headaches when porting is sometimes the ABI. While on Linux > >the first 6 arguments to a function are given in registers, on Windows > >only 4 args are in registers. This can result in bugs when calling > >functions with more than 4 parameters, which are invisible on Linux, due > >to the way 32 bit parameter are stored in registers on x86_64. This > >happened to us already for at least one package. >=20 > Am I right in thinking this can only be an issue if the source includes > assembler code? No. This can be easily trigger by a bug in C code. What happens is this: The 64 bit ABI is defined so that the first function args are passed to the called functions via CPU registers. On Windows the ABI uses 4 such registers(*), on Linux 6(**). All following arguments are passed on the stack. The AMD64 CPUs introduced the following behaviour: If a 32 bit value (for instance, an int in C) is written to a register, the CPU automatically clears the upper 32 bits of the register. For instance: %rdx =3D=3D 0x0123456789abcdef mov.l $0x42,%edx <- This is a 32 bit mov! =3D=3D> %rdx =3D=3D 0x0000000000000042 No sign extension: mov.l $0xffffffff,%edx =3D=3D> %rdx =3D=3D 0x00000000ffffffff Now consider what happens if, for instance, the 5th argument to a stdargs function is expecting a pointer value. The caller calls the function like this: foo (a, b, c, d, 0); The 0 is int, it's not extendend to 64 bit. On Linux, nothing bad happens, because the 0 will be passed over to foo via register R8, so the upper 32 bits are cleared. On Cygwin, the 5th parameter is passed via the stack, 64 bit aligned. The upper 32 bits will not be explicitely written. They will contain random bytes. foo doesn't get a NULL pointer, but something like 0xdeadbeef00000000. Here's an example: $ cat > p.c < int main () { printf ("prepare stack:\n%p\n%p\n%p\n%p\n%p\n%p\n", 0x1111111111111111UL, 0x2222222222222222UL, 0x3333333333333333UL, 0x4444444444444444UL, 0x5555555555555555UL, 0x6666666666666666UL); printf ("\nprint null ptr:\n%p\n%p\n%p\n%p\n%p\n%p\n", 0, 0, 0, 0, 0, 0= ); } EOF $ gcc -g -o p p.c $ ./p The same problem might occur if some code uses a function unprototyped. My favorite example: /* Don't include string,h */ printf ("Error message is: %s\n", strerror (errno)); Long story short, I have no idea if that's your problem at all, but I thought I should at least mention it. Corinna (*) http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_call= ing_convention (**) http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJURkDEAAoJEPU2Bp2uRE+gMAIQAKQta1PnQMb1Ms7lqtPhHSNM ptO8Z+SzoeXDNf+/j8i01FDQFNbOncpKf5e5wjHAJpbwsJo94HR9/rNhM6dA1gUa tX0FMj6uTjWiZAsgUW/c/GkchZukN4+Y1T/mR1k7Z+d1+7dA2/hgpK7V+tViQE1o 56rRvpO9nR41rMpm8GxmsMJO1K+9w4srixDTLROAttcyUfYaCMb7+SoGXDJUukFU EdIn0ecEkWNpaB86u2R+GKyck5cxRpHw7ISMK7nYMFE2XzwmOf18lPN+7NQm3EJF f3Mz6Kj2EUJTJ+3Di/Q5py7JMgv5x+MNjYtfXmwONDzKr7KQVjzjEWx4jkGeCJuF qj3rF31LgKEj3zHWHBke5Rp/3PsQJpRhu2123BVykSxczS4XrYtG4rgLeaMCVWlU a+TWi3bkS4P7BcKjvCi6jgdOX+qHj5fVf4DDgiUrKfzjublWYPX7LjG4uIs7Z8dT gUiqfSPNkPsx8wdnUmhPfrv42JekE2rEwvRMwdLm2IyM8bF91BWOjk169fEnXsOF B9Fr72jKZjgLABTq+e4WI9JsXS8zBgunCZKb/L4eqsHKF6XZASSAndj1hlisec8C wgaPA5hLYJO/8Yjwvmc6EZZ6nrp7HjnRul6qlzQK0ryipboH3jTDrKdBlvxFQ7vA VuaIpGcwm9MhxjgJRkVD =PEI+ -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--