32 bit vs 64 bit Cygwin, followup

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

Re: 32 bit vs 64 bit Cygwin, followup

[Yaakov Selkowitz]

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

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 <yselkowi@redhat.com> 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

Re: 32 bit vs 64 bit Cygwin, followup

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

Please, no top-posting.

On Nov 28 11:06, Sam Habiel wrote:
> Yaakov,
> 
> On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz <yselkowi@redhat.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 32 bit vs 64 bit Cygwin, followup

[Sam Habiel]

On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> 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 <yselkowi@redhat.com> 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

Re: 32 bit vs 64 bit Cygwin, followup

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 32 bit vs 64 bit Cygwin, followup

[Sam Habiel]

On Thu, Nov 29, 2018 at 11:33 AM Corinna Vinschen
<corinna-cygwin@cygwin.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

Re: 32 bit vs 64 bit Cygwin, followup

[Sam Habiel]

On Sat, Feb 2, 2019 at 9:39 AM Sam Habiel <sam.habiel@gmail.com> wrote:
>
> On Thu, Nov 29, 2018 at 11:33 AM Corinna Vinschen
> <corinna-cygwin@cygwin.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;
> }

Sorry. Should say what the error is:

Hp@memphis ~/fis-gtm/build
$ gdb a.exe
GNU gdb (GDB) (Cygwin 8.0.1-1) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.exe...done.
(gdb) b main
Breakpoint 1 at 0x1004011c2: file test.c, line 23.
(gdb) r
Starting program: /home/Hp/fis-gtm/build/a.exe
[New Thread 11672.0xdd0]
[New Thread 11672.0x1230]
[New Thread 11672.0x20ac]
[New Thread 11672.0x43f4]

Thread 1 "a" hit Breakpoint 1, main () at test.c:23
23        PrintFloats (3,3.14159,2.71828,1.41421);
(gdb) s
PrintFloats (n=1) at test.c:6
6       {
(gdb) s
9         printf ("Printing floats:");
(gdb) s
11        va_start(vl,n);
(gdb) s
12        for (i=0;i<n;i++)
(gdb) p vl
$1 = (va_list) 0x3000000008 <error: Cannot access memory at address
0x3000000008>
(gdb) s
[New Thread 11672.0x3f9c]
14          val=va_arg(vl,double);
(gdb) s

Thread 1 "a" received signal SIGSEGV, Segmentation fault.
0x000000010040112f in PrintFloats (n=3) at test.c:14

PS: Running this outside GDB causes Cygwin x64 to hang--and I don't
know how to make it unhang.

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

Re: 32 bit vs 64 bit Cygwin, followup

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]

On Feb  2 09:42, Sam Habiel wrote:
> On Sat, Feb 2, 2019 at 9:39 AM Sam Habiel <sam.habiel@gmail.com> wrote:
> >
> > On Thu, Nov 29, 2018 at 11:33 AM Corinna Vinschen
> > <corinna-cygwin@cygwin.com> wrote:
> > >[...]
> > > One way is to create a SYSV wrapper for each C function called from
> > > assembler.  Assuming this simple scenario:
> > > [...]
> > 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;
> > }
> 
> Sorry. Should say what the error is:
> 
> Hp@memphis ~/fis-gtm/build
> $ gdb a.exe
> [...]
> (gdb) r
> Starting program: /home/Hp/fis-gtm/build/a.exe
> [New Thread 11672.0xdd0]
> [New Thread 11672.0x1230]
> [New Thread 11672.0x20ac]
> [New Thread 11672.0x43f4]
> 
> Thread 1 "a" hit Breakpoint 1, main () at test.c:23
> 23        PrintFloats (3,3.14159,2.71828,1.41421);
> (gdb) s
> PrintFloats (n=1) at test.c:6
> 6       {
> (gdb) s
> 9         printf ("Printing floats:");
> (gdb) s
> 11        va_start(vl,n);
> (gdb) s
> 12        for (i=0;i<n;i++)
> (gdb) p vl
> $1 = (va_list) 0x3000000008 <error: Cannot access memory at address
> 0x3000000008>
> (gdb) s
> [New Thread 11672.0x3f9c]
> 14          val=va_arg(vl,double);
> (gdb) s
> 
> Thread 1 "a" received signal SIGSEGV, Segmentation fault.
> 0x000000010040112f in PrintFloats (n=3) at test.c:14
> 
> PS: Running this outside GDB causes Cygwin x64 to hang--and I don't
> know how to make it unhang.

That's not GCC fault.  You're running varargs, written for the standard
stack layout of the MSABI target from a function with a stack laid out
in SYSV ABI.  That can't work.

If you *have to* use varargs from SYSV ABI functions, you have to define
your own version of them.

But there's another problem with no easy hackaround, the hang you're
observing after the SEGV.

Keep in mind that *Windows* runs the exception handling in the first
place, not Cygwin.  Cygwin only installs a structured exception handler,
but that requires that windows can *find* the exception handler.

To do this, Windows needs to unwind the stack until it finds the
exception handler.  However, you're running a function using the SYSV
stack layout the Windows stack unwinder doesn't know about.  As a
result, this goes nowhere.  The stack unwinder runs wild or, if you're
lucky, just stops in the outermost structured exception handler or some
vectored exception handler.

I'm not sure there is a solution to that.  What you could try is to
install a structured exception handler inside the SYSV call.  You may
have to do this inside each and every SYSV function which *may* crash to
keep the Windows stack unwinder having to unwind to the calling function
at all.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 32 bit vs 64 bit Cygwin, followup

[Sam Habiel]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

>That's not GCC fault.  You're running varargs, written for the standard
>stack layout of the MSABI target from a function with a stack laid out
>in SYSV ABI.  That can't work.

I did some research to see how to write my own version of varargs (the
code base is already instrumented to do different versions of varargs
based on operating system). What I noticed though is that after
disassembling code for win64 abi vs sysv abi, it seems like gcc/crt is
attempting to do the right thing. There is different code for sysv vs
win64 for va_start.

sysv:
10        va_list vl;
11        va_start(vl,n);
   0x00000001004010e4 <+100>:   movl   $0x8,-0xc8(%rbp)
   0x00000001004010ee <+110>:   movl   $0x30,-0xc4(%rbp)
   0x00000001004010f8 <+120>:   lea    0x10(%rbp),%rax
   0x00000001004010fc <+124>:   mov    %rax,-0xc0(%rbp)
   0x0000000100401103 <+131>:   lea    -0xb0(%rbp),%rax
   0x000000010040110a <+138>:   mov    %rax,-0xb8(%rbp)

win64:
10        va_list vl;
11        va_start(vl,n);
   0x00000001004010a3 <+35>:    lea    0x18(%rbp),%rax
   0x00000001004010a7 <+39>:    mov    %rax,-0x18(%rbp)

So there may be a incomplete support for varargs for the sysv abi--but buggy.

I attached the disassembly as well as the testing programs for your convenience.

--Sam

[-- Attachment #2: dis_sysv.txt --]
[-- Type: text/plain, Size: 2929 bytes --]

Dump of assembler code for function PrintFloats:
test_sysvabi.c:
6	{
   0x0000000100401080 <+0>:	push   %rbp
   0x0000000100401081 <+1>:	mov    %rsp,%rbp
   0x0000000100401084 <+4>:	sub    $0x100,%rsp
   0x000000010040108b <+11>:	mov    %edi,-0xd4(%rbp)
   0x0000000100401091 <+17>:	mov    %rsi,-0xa8(%rbp)
   0x0000000100401098 <+24>:	mov    %rdx,-0xa0(%rbp)
   0x000000010040109f <+31>:	mov    %rcx,-0x98(%rbp)
   0x00000001004010a6 <+38>:	mov    %r8,-0x90(%rbp)
   0x00000001004010ad <+45>:	mov    %r9,-0x88(%rbp)
   0x00000001004010b4 <+52>:	test   %al,%al
   0x00000001004010b6 <+54>:	je     0x1004010d8 <PrintFloats+88>
   0x00000001004010b8 <+56>:	movaps %xmm0,-0x80(%rbp)
   0x00000001004010bc <+60>:	movaps %xmm1,-0x70(%rbp)
   0x00000001004010c0 <+64>:	movaps %xmm2,-0x60(%rbp)
   0x00000001004010c4 <+68>:	movaps %xmm3,-0x50(%rbp)
   0x00000001004010c8 <+72>:	movaps %xmm4,-0x40(%rbp)
   0x00000001004010cc <+76>:	movaps %xmm5,-0x30(%rbp)
   0x00000001004010d0 <+80>:	movaps %xmm6,-0x20(%rbp)
   0x00000001004010d4 <+84>:	movaps %xmm7,-0x10(%rbp)

7	  int i;
8	  double val;
9	  printf ("Printing floats:");
   0x00000001004010d8 <+88>:	lea    0x1f21(%rip),%rcx        # 0x100403000
   0x00000001004010df <+95>:	callq  0x100401270 <printf>

10	  va_list vl;
11	  va_start(vl,n);
   0x00000001004010e4 <+100>:	movl   $0x8,-0xc8(%rbp)
   0x00000001004010ee <+110>:	movl   $0x30,-0xc4(%rbp)
   0x00000001004010f8 <+120>:	lea    0x10(%rbp),%rax
   0x00000001004010fc <+124>:	mov    %rax,-0xc0(%rbp)
   0x0000000100401103 <+131>:	lea    -0xb0(%rbp),%rax
   0x000000010040110a <+138>:	mov    %rax,-0xb8(%rbp)

12	  for (i=0;i<n;i++)
   0x0000000100401111 <+145>:	movl   $0x0,-0xb4(%rbp)
   0x000000010040111b <+155>:	jmp    0x100401163 <PrintFloats+227>

13	  {
14	    val=va_arg(vl,double);
   0x000000010040111d <+157>:	mov    -0xc8(%rbp),%rax
   0x0000000100401124 <+164>:	lea    0x8(%rax),%rdx
   0x0000000100401128 <+168>:	mov    %rdx,-0xc8(%rbp)
   0x000000010040112f <+175>:	movsd  (%rax),%xmm0
   0x0000000100401133 <+179>:	movsd  %xmm0,-0xc0(%rbp)

15	    printf (" [%.2f]",val);
   0x000000010040113b <+187>:	movsd  -0xc0(%rbp),%xmm1
   0x0000000100401143 <+195>:	movsd  -0xc0(%rbp),%xmm0
   0x000000010040114b <+203>:	movq   %xmm0,%rdx
   0x0000000100401150 <+208>:	lea    0x1eba(%rip),%rcx        # 0x100403011
   0x0000000100401157 <+215>:	callq  0x100401270 <printf>

12	  for (i=0;i<n;i++)
   0x000000010040115c <+220>:	addl   $0x1,-0xb4(%rbp)
   0x0000000100401163 <+227>:	mov    -0xb4(%rbp),%eax
   0x0000000100401169 <+233>:	cmp    -0xd4(%rbp),%eax
   0x000000010040116f <+239>:	jl     0x10040111d <PrintFloats+157>

16	  }
17	  va_end(vl);
18	  printf ("\n");
   0x0000000100401171 <+241>:	mov    $0xa,%ecx
   0x0000000100401176 <+246>:	callq  0x100401280 <putchar>

19	}
   0x000000010040117b <+251>:	nop
   0x000000010040117c <+252>:	leaveq 
   0x000000010040117d <+253>:	retq   
End of assembler dump.

[-- Attachment #3: dis_win64.txt --]
[-- Type: text/plain, Size: 2093 bytes --]

Dump of assembler code for function PrintFloats:
test_win64abi.c:
6	{
   0x0000000100401080 <+0>:	push   %rbp
   0x0000000100401081 <+1>:	mov    %rsp,%rbp
   0x0000000100401084 <+4>:	sub    $0x40,%rsp
   0x0000000100401088 <+8>:	mov    %ecx,0x10(%rbp)
   0x000000010040108b <+11>:	mov    %rdx,0x18(%rbp)
   0x000000010040108f <+15>:	mov    %r8,0x20(%rbp)
   0x0000000100401093 <+19>:	mov    %r9,0x28(%rbp)

7	  int i;
8	  double val;
9	  printf ("Printing floats:");
   0x0000000100401097 <+23>:	lea    0x1f62(%rip),%rcx        # 0x100403000
   0x000000010040109e <+30>:	callq  0x1004011a0 <printf>

10	  va_list vl;
11	  va_start(vl,n);
   0x00000001004010a3 <+35>:	lea    0x18(%rbp),%rax
   0x00000001004010a7 <+39>:	mov    %rax,-0x18(%rbp)

12	  for (i=0;i<n;i++)
   0x00000001004010ab <+43>:	movl   $0x0,-0x4(%rbp)
   0x00000001004010b2 <+50>:	jmp    0x1004010e8 <PrintFloats+104>

13	  {
14	    val=va_arg(vl,double);
   0x00000001004010b4 <+52>:	mov    -0x18(%rbp),%rax
   0x00000001004010b8 <+56>:	lea    0x8(%rax),%rdx
   0x00000001004010bc <+60>:	mov    %rdx,-0x18(%rbp)
   0x00000001004010c0 <+64>:	movsd  (%rax),%xmm0
   0x00000001004010c4 <+68>:	movsd  %xmm0,-0x10(%rbp)

15	    printf (" [%.2f]",val);
   0x00000001004010c9 <+73>:	movsd  -0x10(%rbp),%xmm1
   0x00000001004010ce <+78>:	movsd  -0x10(%rbp),%xmm0
   0x00000001004010d3 <+83>:	movq   %xmm0,%rdx
   0x00000001004010d8 <+88>:	lea    0x1f32(%rip),%rcx        # 0x100403011
   0x00000001004010df <+95>:	callq  0x1004011a0 <printf>

12	  for (i=0;i<n;i++)
   0x00000001004010e4 <+100>:	addl   $0x1,-0x4(%rbp)
   0x00000001004010e8 <+104>:	mov    -0x4(%rbp),%eax
   0x00000001004010eb <+107>:	cmp    0x10(%rbp),%eax
   0x00000001004010ee <+110>:	jl     0x1004010b4 <PrintFloats+52>

16	  }
17	  va_end(vl);
18	  printf ("\n");
   0x00000001004010f0 <+112>:	mov    $0xa,%ecx
   0x00000001004010f5 <+117>:	callq  0x1004011b0 <putchar>

19	}
   0x00000001004010fa <+122>:	nop
   0x00000001004010fb <+123>:	add    $0x40,%rsp
   0x00000001004010ff <+127>:	pop    %rbp
   0x0000000100401100 <+128>:	retq   
End of assembler dump.

[-- Attachment #4: test_sysvabi.c --]
[-- Type: application/octet-stream, Size: 458 bytes --]

/* 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;
}

[-- Attachment #5: test_win64abi.c --]
[-- Type: application/octet-stream, Size: 431 bytes --]

/* va_start example */
#include <stdio.h>      /* printf */
#include <stdarg.h>     /* va_list, va_start, va_arg, va_end */

void 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;
}

[-- Attachment #6: Type: text/plain, Size: 219 bytes --]


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

Re: 32 bit vs 64 bit Cygwin, followup

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On Feb  4 09:16, Sam Habiel wrote:
> >That's not GCC fault.  You're running varargs, written for the standard
> >stack layout of the MSABI target from a function with a stack laid out
> >in SYSV ABI.  That can't work.
> 
> I did some research to see how to write my own version of varargs (the
> code base is already instrumented to do different versions of varargs
> based on operating system). What I noticed though is that after
> disassembling code for win64 abi vs sysv abi, it seems like gcc/crt is
> attempting to do the right thing. There is different code for sysv vs
> win64 for va_start.
> 
> sysv:
> 10        va_list vl;
> 11        va_start(vl,n);
>    0x00000001004010e4 <+100>:   movl   $0x8,-0xc8(%rbp)
>    0x00000001004010ee <+110>:   movl   $0x30,-0xc4(%rbp)
>    0x00000001004010f8 <+120>:   lea    0x10(%rbp),%rax
>    0x00000001004010fc <+124>:   mov    %rax,-0xc0(%rbp)
>    0x0000000100401103 <+131>:   lea    -0xb0(%rbp),%rax
>    0x000000010040110a <+138>:   mov    %rax,-0xb8(%rbp)
> 
> win64:
> 10        va_list vl;
> 11        va_start(vl,n);
>    0x00000001004010a3 <+35>:    lea    0x18(%rbp),%rax
>    0x00000001004010a7 <+39>:    mov    %rax,-0x18(%rbp)
> 
> So there may be a incomplete support for varargs for the sysv abi--but buggy.
> 
> I attached the disassembly as well as the testing programs for your convenience.

There's nothing for me to do here.  You still have to make sure
to choose the right varargs version and if there's really a bug,
you really should report it to GCC.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]