32 bit vs 64 bit Cygwin, followup

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

32 bit vs 64 bit Cygwin, followup

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

Reply | Threaded
Open this post in threaded view
|

Re: 32 bit vs 64 bit Cygwin, followup

Yaakov Selkowitz-2
On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:

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

-mabi=sysv ?

> 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

Reply | Threaded
Open this post in threaded view
|

Re: 32 bit vs 64 bit Cygwin, followup

Sam Habiel
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
On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz <[hidden email]> wrote:

>
> On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:
> > 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.
>
> -mabi=sysv ?
>
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: 32 bit vs 64 bit Cygwin, followup

Corinna Vinschen-2
Please, no top-posting.

On Nov 28 11:06, Sam Habiel wrote:

> Yaakov,
>
> On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz <[hidden email]> wrote:
> >
> > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:
> > > 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.
> >
> > -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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 32 bit vs 64 bit Cygwin, followup

Sam Habiel
On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen
<[hidden email]> wrote:

>
> Please, no top-posting.
>
> On Nov 28 11:06, Sam Habiel wrote:
> > Yaakov,
> >
> > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz <[hidden email]> wrote:
> > >
> > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:
> > > > 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.
> > >
> > > -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

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

Reply | Threaded
Open this post in threaded view
|

Re: 32 bit vs 64 bit Cygwin, followup

Corinna Vinschen-2
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

signature.asc (849 bytes) Download Attachment