Discussion:
New 64 bit Cygwin DLL
Corinna Vinschen
2013-03-19 09:46:22 UTC
Permalink
Hi guys,


at long last, it looks like we found the real bug which was the reason
for the random crashes.

There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
it turned out that it was missing two crucial features:

- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.

- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.

So, here we go with a new 64 bit Cygwin version 1.7.18-9. You'll
find the packages under ftp://cygwin.com/pub/cygwin/64bit/release.

Please give it a try.


Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Christopher Faylor
2013-03-19 16:08:19 UTC
Permalink
Post by Corinna Vinschen
Hi guys,
at long last, it looks like we found the real bug which was the reason
for the random crashes.
There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.
- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.
That's not really true for the 32-bit version. eax and ebx aren't
normally saved around function calls but they are for sigdelayed. It
doesn't currently save floating point and debugging registers though.

I thought I mentioned when you asked what could be causing these
random problems that it was likely to be related to signals. I
guess I just thought it though since I can't find the email which
I thought I sent suggesting it. Sorry.

cgf
Corinna Vinschen
2013-03-19 16:24:07 UTC
Permalink
Post by Christopher Faylor
Post by Corinna Vinschen
Hi guys,
at long last, it looks like we found the real bug which was the reason
for the random crashes.
There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.
- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.
That's not really true for the 32-bit version. eax and ebx aren't
normally saved around function calls but they are for sigdelayed.
Yes, I saw that. And I thought it's necessary only for 32 bit due to
the different calling conventions, so I only saved the caller-saved and
return value registers on x86_64. So, in fact, this is entirely my own
fault.
Post by Christopher Faylor
It doesn't currently save floating point and debugging registers though.
There may be situations in which it might be helpful to save and restore
the FP regs on 32 bit as well, though. For instance, printf is a SIGFE
function dealing with FP values.
Post by Christopher Faylor
I thought I mentioned when you asked what could be causing these
random problems that it was likely to be related to signals. I
guess I just thought it though since I can't find the email which
I thought I sent suggesting it. Sorry.
No worries.


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Christopher Faylor
2013-03-19 16:29:01 UTC
Permalink
Post by Corinna Vinschen
Post by Christopher Faylor
Post by Corinna Vinschen
Hi guys,
at long last, it looks like we found the real bug which was the reason
for the random crashes.
There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.
- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.
That's not really true for the 32-bit version. eax and ebx aren't
normally saved around function calls but they are for sigdelayed.
Yes, I saw that. And I thought it's necessary only for 32 bit due to
the different calling conventions, so I only saved the caller-saved and
return value registers on x86_64. So, in fact, this is entirely my own
fault.
Post by Christopher Faylor
It doesn't currently save floating point and debugging registers though.
There may be situations in which it might be helpful to save and restore
the FP regs on 32 bit as well, though. For instance, printf is a SIGFE
function dealing with FP values.
Right.

cgf
Corinna Vinschen
2013-03-20 09:58:46 UTC
Permalink
Post by Christopher Faylor
Post by Corinna Vinschen
Post by Christopher Faylor
Post by Corinna Vinschen
Hi guys,
at long last, it looks like we found the real bug which was the reason
for the random crashes.
There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.
- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.
That's not really true for the 32-bit version. eax and ebx aren't
normally saved around function calls but they are for sigdelayed.
Yes, I saw that. And I thought it's necessary only for 32 bit due to
the different calling conventions, so I only saved the caller-saved and
return value registers on x86_64. So, in fact, this is entirely my own
fault.
Post by Christopher Faylor
It doesn't currently save floating point and debugging registers though.
There may be situations in which it might be helpful to save and restore
the FP regs on 32 bit as well, though. For instance, printf is a SIGFE
function dealing with FP values.
Right.
While we're at it, does i686 use the 387 FP regs or the xmms regs for FP?
I'm pretty fuzzy in this math stuff. I know that x86_64 uses the xmms
regs, but that's it...


Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Kai Tietz
2013-03-20 10:07:05 UTC
Permalink
Post by Corinna Vinschen
Post by Christopher Faylor
Post by Corinna Vinschen
Post by Christopher Faylor
Post by Corinna Vinschen
Hi guys,
at long last, it looks like we found the real bug which was the reason
for the random crashes.
There's a function sigdelayed, written in assembler, which is called
when a thread got a signal. Due to the way the function is called,
- It can be called with any stack alignment, but on x86_64 it's important
that the stack is always 16 byte aligned when calling functions. So
sigdelayed had to make sure to align the stack before trundling along.
- sigdelayed only saved and restored the CPU registers which are
callee-saved in the Microsoft ABI, plus the registers used for the
return value of a function. Given how sigdelayed is called, this
was insufficient. The original, interrupted function needs the CPU
in its original state when sigdelayed returns to it, so sigdelayed
has to save and restore *all* registers.
That's not really true for the 32-bit version. eax and ebx aren't
normally saved around function calls but they are for sigdelayed.
Yes, I saw that. And I thought it's necessary only for 32 bit due to
the different calling conventions, so I only saved the caller-saved and
return value registers on x86_64. So, in fact, this is entirely my own
fault.
Post by Christopher Faylor
It doesn't currently save floating point and debugging registers though.
There may be situations in which it might be helpful to save and restore
the FP regs on 32 bit as well, though. For instance, printf is a SIGFE
function dealing with FP values.
Right.
While we're at it, does i686 use the 387 FP regs or the xmms regs for FP?
I'm pretty fuzzy in this math stuff. I know that x86_64 uses the xmms
regs, but that's it...
x86 uses by default x87, and x64 always SSE. There are switches to
change use of FPU-instructions and mode, but in general I wouldn't
recomment to use them.

Kai

Loading...