Mail Archives: cygwin/2019/02/02/09:39:33
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:mime-version:references:in-reply-to:from:date
|
| :message-id:subject:to:content-type; q=dns; s=default; b=lWS3sJZ
|
| QOV6ByionPna7LCZlCJvugGZmTm9jZaoUGNZm1n6+dip1nmVLHqKJuEPq0+JZvb9
|
| gCawoaPpEKBSamrJV4Zb6AaH6DwUI4JAdiplx/7aK1N4Loif6t6x/4jjMeww5e9V
|
| Vs+E04kmEt1FP7+9xOBr8kFcEfn7ZF0mBDeM=
|
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:mime-version:references:in-reply-to:from:date
|
| :message-id:subject:to:content-type; s=default; bh=OjX7oSRey+416
|
| +1waGLp0w5f7H8=; b=Ccwd/3499IANoeXSk1RB9oIGwD34/6GR7DZiSdmXdWDgo
|
| +yZ9d4cnOzg3vj8wnIJ1ErQZGxwt/kMHWevOh3MsX8CmDNzIuvyVXx17w3Z47FiE
|
| Dbfkja9zwVatfhmAkf+l8C0ZzpC9O2wdsrhjpJWusC7zDIGP2597ikNCbffra4=
|
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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=luck, Printing, UD:M, expertise
|
X-HELO: | mail-wr1-f49.google.com
|
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=i3aEX25863nHj2agJ6mpeCwBBJAsWcTfUmpu2KJHzK0=; b=Z4U0SgTyS1Ne1wpO5NOB2gEJ52vG4udkvnFwLHwn/4h//SnUcuByZD4usJjnXWs8Hu wS4+ge76BCy/Cab4kGpe4iJ1ARS1jpzIh0xJLqO76XAqVcxYHG9SAkJnyZlSGX6ZU3Hi Np7eGqbaLqKrkwyzitlRFOxkjnLhfwIAxdxKleCF1t7T0Qoh8bY/5UfFO2WgNiE4d+fL 2ZdYqxlOdaL9cUxct1MtdFBkmTxXyESg4uFnPfYQZW6usO4piiP9J82kb8wI3DRx47wq Msj6XFsDQp5MJbWtbmUL3cl1i7CKrAEy1HPXpOYHtXZF0qBAQWtnsupyU4+/Yj38ewar 8eZw==
|
MIME-Version: | 1.0
|
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>
|
In-Reply-To: | <20181129163327.GD30649@calimero.vinschen.de>
|
From: | Sam Habiel <sam DOT habiel AT gmail DOT com>
|
Date: | Sat, 2 Feb 2019 09:39:08 -0500
|
Message-ID: | <CABHT961E1J3z_QjDr_PQu6gerUqsNnHN6NMBSBNas=4mbcNBiQ@mail.gmail.com>
|
Subject: | Re: 32 bit vs 64 bit Cygwin, followup
|
To: | cygwin AT cygwin DOT com, Sam Habiel <sam DOT habiel AT gmail DOT com>
|
X-IsSubscribed: | yes
|
On Thu, Nov 29, 2018 at 11:33 AM Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
>
> 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-x86-64/).
> > > > > > I don't have the expertise nor the time to rewrite a lot of assembly
> > > > > > code to use the Windows x64 ABI. There are about 100 source code files
> > > > > > that are in assembly.
> > > > >
> > > > > -mabi=sysv ?
> > > > >
> > > > 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:
> >
> > 1. There are frequent calls from the C code to Assembly.
> > 2. There are also frequent calls from Assembly to C code.
> >
> > Looks like compiling the .s files with the -mabi=sysv 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
>
> --
> Corinna Vinschen
> Cygwin Maintainer
Corinna et al.,
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=0;i<n;i++)
{
val=va_arg(vl,double);
printf (" [%.2f]",val);
}
va_end(vl);
printf ("\n");
}
int main ()
{
PrintFloats (3,3.14159,2.71828,1.41421);
return 0;
}
--
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
- Raw text -