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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=N1G1mznDdgrXULnD
	o3pY3dacFweuDWLJRgDTaF+SaEbc2A9xwhkWrGQb/4jx5eAas70RiMVJlRRZWtdl
	A4F1JkTC0jJ6ALuqoiaqjYgiiHKmYGOoz8W9OxTXcJdzjHdBSt51fpLEYSgywQXS
	mb+6TX6HPXMeqL951mB48GJ+6bo=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=mSvIPmwjIqY41cV7B16+wS
	2SrCo=; b=kjj35X8t1zYXRtDdRwYutqy58EOI1UOFApjY+YK996JAz6WHieBiht
	jg37Fx2m2J9kaXM5lF1TPIvofJKaFPHKr7G043UoKRTgw466qtpN9pn2UnDtqQQ6
	Yt5bXoqfroLV2rGDxgVSMNs6nr1Aft8UukC9ZA/O9KG6UqdIcmI6s=
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=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_RP_RNBL,SPF_FAIL,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=H*M:a594, HContent-Transfer-Encoding:8bit
X-HELO: gateway22.websitewelcome.com
Subject: Re: Why is __unix__ defined, and not __WINDOWS__ ?
To: cygwin AT cygwin DOT com
References: <5fbb6229-da17-c056-19b9-9819c684a8ad AT agner DOT org> <8e9bfbb4-2139-639d-afaa-dfbacac1a8d9 AT t-online DOT de> <dfd043fb-620a-81a1-1611-91a982fc96cd AT agner DOT org> <72c5e82b-38f0-8701-93fe-5682176017b6 AT SystematicSw DOT ab DOT ca>
From: Agner Fog <agner AT agner DOT org>
Message-ID: <726f278f-c0b5-7578-a594-e7e249981104@agner.org>
Date: Mon, 13 May 2019 16:49:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <72c5e82b-38f0-8701-93fe-5682176017b6@SystematicSw.ab.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes
Note-from-DJ: This may be spam

On 13/05/2019 07.39, Brian Inglis wrote:
> Not quite I believe Cygwin 64 bit programs follow the Unix 64 bit LP64 C
> programming memory model and the System V AMD64 ABI *NOT* the Windows 64 bit
> ILP64 C programming memory model and Microsoft x64 calling convention; see:
> 	http://www.unix.org/version2/whatsnew/lp64_wp.html
> 	https://en.wikipedia.org/wiki/X86_calling_conventions
> - the interface has to be managed by the Cygwin1 dll.

I tried this:

> int test (int x) {
>     return x + 1;
> }
g++ -S -O2 t.cpp

Assembly output from g++ or clang:

> _Z4testi:
> .LFB0:
>         .seh_endprologue
>         leal    1(%rcx), %eax
>         ret
>         .seh_endproc

The Win64 ABI has the paramter in ecx or rcx, the SysV ABI has it in edi.

A dump of the object file shows it is in COFF64 format.

The object file obeys the Win64 ABI and links directly into a Win64 
project. The cygwin dll is not needed if the rest of the executable is 
made with another compiler.

The executable runs under Windows, not under Linux.



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