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=macXuCGgKD73r2ZDJV/pvcO9qSAqRCvRMCWdyzZ2zv/wMc0PnXvpK 53uDjGIuwK3FC/O7wV/eENoBVKadD1WjK8Z42PQX4W0X1S70zmIZxZZxuM7ueobq incxX9tUNHsiv6EiedmmHexGW4ECMAHR9nw8eI/l6HWTnWl4tokjRU= 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=uLmDMfdX31l2eLIUXw8pDERA11E=; b=AztLEO4mpzLgliToOkc5xCaCSCaE Q3d+fTQdPE97g3cGLB6NpE5AuFRpv7cBqmjCL6wrU5tZB+gYC+73Z/yuX04Xtuss 14opINmeT+7tQtRauLDx+RQePqiJMVRcy0sbhOYdyWcPBSnuO0OyAyynBTuN0s7+ wB6G/LZdynSru44= 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-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= X-HELO: mout.kundenserver.de Date: Thu, 29 Nov 2018 17:33:27 +0100 From: Corinna Vinschen To: Sam Habiel , cygwin AT cygwin DOT com Subject: Re: 32 bit vs 64 bit Cygwin, followup Message-ID: <20181129163327.GD30649@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: Sam Habiel , cygwin AT cygwin DOT com References: <20181129085816 DOT GV30649 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6zipuvUKAEymKn2g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) --6zipuvUKAEymKn2g Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Nov 29 10:18, Sam Habiel wrote: > On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen wrote: > > On Nov 28 11:06, Sam Habiel wrote: > > > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz wrote: > > > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote: > > > > > [...] > > > > > GT.M contains a large > > > > > amount of assembly code, written to run on the x32 Linux ABI and = the > > > > > AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on > > > > > Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI, > > > > > which is very different than the AMD ABI (more detail here: > > > > > https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x8= 6-64/). > > > > > I don't have the expertise nor the time to rewrite a lot of assem= bly > > > > > code to use the Windows x64 ABI. There are about 100 source code = files > > > > > that are in assembly. > > > > > > > > -mabi=3Dsysv ? > > > > > > > Are you telling me that gcc has a flag to support AMD ABI on Cygwin > > > x64? The assembly code is not standalone; it gets called from C code > > > and calls C code. > > > > That's what he's telling you. However, you have to interact with the MS > > ABI(*) as well as soon as you call external library functions so it > > makes sense to keep your C code in MS ABI. For the assembler functions, > > you can just tell the compiler they are in SYSV ABI by adding a function > > attribute to the declaration: > > > > int asm_func (args) __attribute__ ((sysv_abi)) > > > > Good luck, > > Corinna > > > > (*) Just keep in mind that Cygwin is LP64, not LLP64: > > https://cygwin.com/faq/faq.html#faq.programming.64bitporting > > [...] > [...] > This sounds very promising, but I would like a clarification; because > I think you covered 50% of the issue: >=20 > 1. There are frequent calls from the C code to Assembly. > 2. There are also frequent calls from Assembly to C code. >=20 > Looks like compiling the .s files with the -mabi=3Dsysv flag and > declaring the function in C with the __attribute__ ((sysv_abi)) will > fix #1. You shouldn't have to use the flag when building the assembler files, they are using SYSV ABI anyway. In fact, while Yaakov is right, basically, I think in your scenario you should only use the GCC function attribute since that allows more fine-grained control. Just stick to MS ABI by default and only perform the SYSV ABI juggle where required to interact with the assembler code. > How about #2? I don't see an easy solution. The assembly code puts > together the parameters in the registers in the sysv way (rdi, rsi, > rdx, rcx, r8, r9), not rcx, rdx, r8, and r9. One way is to create a SYSV wrapper for each C function called from assembler. Assuming this simple scenario: There's a C function foo(), which is called from assembler as well as from other C functions. extern long foo (long, double, int, long); For the "normal" (i.e. MS ABI) C code add this in front of the above declaration: #define foo(a,b,c,d) __foo((a),(b),(c),(d)) So the C function is renamed to __foo and C code will call __foo. Add a wrapper C file to add a function foo with SYSV ABI, calling __foo: #undef foo long __attribute__ ((sysv_abi)) foo (long a, double b, int c, long d) { return __foo (a,b,c,d); } That should do it. Of course there may be more complicated cases, but I leave them as excercise for the reader, and only you are in a position to know them ;) HTH, Corinna --=20 Corinna Vinschen Cygwin Maintainer --6zipuvUKAEymKn2g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlwAFNcACgkQ9TYGna5E T6CInA//SCOijJCTfjy56LxWtKk3bk6lUlmHuVd0eM9ht7L5gVVD6ICTu1bdB92z Q0+KZF+S7Itg/KZAlGgCY+IhUcpP8IfRfD7CoQmy2/BjsdPVAFPpBbCDG0VlpmMG 4IYE7kjAd2nwb6xCKZVi0Yt6MCUJTEmq1Y0biR1qBzd7uL/2yl8YfdQkiZ+Y9Ko+ 14BJQIGSCITUcUdowxQWbP3kxSGXXEo+r44ot7prdwW0HeJfv/6mow5uzQfx9Bpo Zhj9SxQ79QVaV8h8fLA5yp2PGhvcbuOiVhlzbtHdnJquHQw6eyqzmeVce52eo8VJ TLzuLYeQIk15klaVaQpIZleXrpVspdY1yuBgtLebYzoG4GeyVxShU/rGsNejRHw+ 9MdACOrZ0nbxAHucRQxWPZMTyOiNHcL9LC1ZM5CA9QRuMIcN8FHbRleikhnbNYui Qi8pfFSIxg2icQkSCIyc/J4OWx1d5ZUPaAAmGhtzfwwQgmTfTBqwnXfHrGuXzjdI Jo25WiNdWLaT4rSJIs4k7O077p8t2e6WdKZ1G74k92CTsU+7Lu151EWtfS23Wf40 dmUELMuDwk2S3j/pElGUyJ8hTjDLkWrSONihoBRGgKxl8S6+8x0YXM2uNsXNCy3i fYSTaJMKVIFoy9GhNVpNeKuP6aKPNTd/FLTEmPuTrBOZtvnLnMU= =fyQo -----END PGP SIGNATURE----- --6zipuvUKAEymKn2g--