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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=GQWcUPhkEklC5OVSiYFoGKmVv9CVrEu2dkXwCoAAu2U
	E6uQBqmE/rvXt6TWks9D5X+YDTj9h6PB42C6uDPkrkpiAO3kwBqQhUepQmp5W8vu
	jhWBF5Xq7zzH06fXsXFX2WQDFvap78Trq3qBX1EFy/cv+b9hS/CQihGDFoO49FPQ
	=
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:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 s=default; bh=9tc/TEVup2RE3GAAIOGgcSKa+2c=; b=xC1UY+BJUo/eAapfJ
	v6caD+FGpnhyLxTy4H9QZYob2T8a8slXkWP0+irHFAFTOGKq4gn/0xJRlx3JX9vP
	OdbpOoYGhUSZkgank06KVAiClkUvJScwPyomRRag8FWRVFnCIBTFzgJyX7cUVpCy
	fvUSQeSbBrUZ44w/Dn5bf7FOx8=
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-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO: limerock01.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Message-ID: <54465121.6000603@cornell.edu>
Date: Tue, 21 Oct 2014 08:27:13 -0400
From: Ken Brown <kbrown AT cornell DOT edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Threads
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> <20141021111724 DOT GA12476 AT calimero DOT vinschen DOT de>
In-Reply-To: <20141021111724.GA12476@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

On 10/21/2014 7:17 AM, Corinna Vinschen wrote:
> 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.
>>
>> 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 == 0x0123456789abcdef
>
>    mov.l $0x42,%edx		<- This is a 32 bit mov!
>
>    ==> %rdx == 0x0000000000000042
>
>    No sign extension:
>
>    mov.l $0xffffffff,%edx
>
>    ==> %rdx == 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 <<EOF
>    #include <stdio.h>
>
>    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.

Thanks for the explanation!

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