32 bit vs 64 bit Cygwin, followup

Discussion:

Sam Habiel

2018-11-26 19:07:46 UTC

Hello everybody,

In this message
(https://www.sourceware.org/ml/cygwin/2018-11/msg00190.html), Corinna
(Hi Corinna!) says:

"Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause."

I would like to mention why I am still using 32 bit Cygwin.

I maintain a port of a database called GT.M
(https://en.wikipedia.org/wiki/GT.M) on Cygwin. I work with Electronic
Medical Records that run on this database. 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.

By the way, thank you for the Async IO APIs. I needed those for newer
versions of GT.M and was able to port it successfully to Cygwin x32.

--Sam

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

Yaakov Selkowitz

2018-11-28 16:00:59 UTC

Permalink

Post by Sam Habiel
Hello everybody,
In this message
(https://www.sourceware.org/ml/cygwin/2018-11/msg00190.html), Corinna
"Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost cause."
I would like to mention why I am still using 32 bit Cygwin.
I maintain a port of a database called GT.M
(https://en.wikipedia.org/wiki/GT.M) on Cygwin. I work with Electronic
Medical Records that run on this database. 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,
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 ?

Post by Sam Habiel
By the way, thank you for the Async IO APIs. I needed those for newer
versions of GT.M and was able to port it successfully to Cygwin x32.

--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Sam Habiel

2018-11-28 16:06:37 UTC

Permalink

Yaakov,

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.

--Sam

Post by Yaakov Selkowitz

-mabi=sysv ?

Post by Sam Habiel
By the way, thank you for the Async IO APIs. I needed those for newer
versions of GT.M and was able to port it successfully to Cygwin x32.

--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.

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

Corinna Vinschen

2018-11-29 08:58:16 UTC

Permalink

Please, no top-posting.

Post by Sam Habiel
Yaakov,

Post by Yaakov Selkowitz

-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

--
Corinna Vinschen
Cygwin Maintainer

Sam Habiel

2018-11-29 15:18:37 UTC

Permalink

On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen

Post by Corinna Vinschen
Please, no top-posting.

Post by Sam Habiel
Yaakov,

Post by Yaakov Selkowitz

-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
int asm_func (args) __attribute__ ((sysv_abi))
Good luck,
Corinna
https://cygwin.com/faq/faq.html#faq.programming.64bitporting
--
Corinna Vinschen
Cygwin Maintainer

I use Gmail. Woe is me. And I stick with the defaults. A bit hard to
not top post due to my typical habits. Sorry!

Thank you for your reply Corinna.

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.

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.

Here's an example call:
https://github.com/shabiel/fis-gtm/blob/master/sr_x86_64/opp_tstart.s;
all the other asm code is in the same folder.

--Sam

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

Corinna Vinschen

2018-11-29 16:33:27 UTC

Permalink

Post by Sam Habiel

Post by Corinna Vinschen

Post by Sam Habiel

Post by Yaakov Selkowitz

Post by Sam Habiel
[...]
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,
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
int asm_func (args) __attribute__ ((sysv_abi))
Good luck,
Corinna
https://cygwin.com/faq/faq.html#faq.programming.64bitporting
[...]

[...]
This sounds very promising, but I would like a clarification; because
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.

Post by Sam Habiel
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