| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Based on https://sourceware.org/pipermail/cygwin-patches/2025q3/014154.html
suggestion, this patch implements +/-4GB relocations for AArch64 in the mkimport
script by using adrp and ldr instructions. This change required update
in winsup/cygwin/mm/malloc_wrapper.cc where those instructions are
decoded to get target import address.
Signed-off-by: Radek Bartoň <radek.barton@microsoft.com>
|
|
This patch aspires to provide only minimal changes to
`winsup/cygwin/scripts/gendef` allowing to pass the AArch64 build. It does not
provide any implementations of the generated routines.
Signed-off-by: Radek Bartoň <radek.barton@microsoft.com>
|
|
This patch ports winsup/cygwin/scripts/mkimport script to AArch64, namely
implements relocation to the imp_sym.
Signed-off-by: Radek Bartoň <radek.barton@microsoft.com>
|
|
Signed-off-by: Radek Bartoň <radek.barton@microsoft.com>
|
|
x86_64 ABI requires the direction flag in CPU flags register cleared.
https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions
However, currently that flag is not maintained in signal handler.
Therefore, if the signal handler is called when that flag is set, it
destroys the data and may crash if rep instruction is used in the
signal handler. With this patch, the direction flag is cleared in
sigdelayed() by adding cld instruction.
Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257704.html
Fixes: 1fd5e000ace5 ("import winsup-2000-02-17 snapshot")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vischen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
|
|
Commit a942476236b5 ("Cygwin: sigdelayed: pop return address from
signal stack earlier") failed to take two facts into account:
- _cygtls::call_signal_handler() potentially needs the return address
as well, and
- the signal handler may be interrupted by another signal.
Revert the change in sigdelayed() and handle the signal stack manipulation
in _cygtls::call_signal_handler() instead.
Given we're poping the latest addresses from the signal stack early,
there's no need for a big signal stack anymore. Reduce the size of the
stack to 4 entries, plus one dummy entry. Move _cygtls::pop() from
assembler to C++ code and make sure that stackptr neither underflows nor
overflows the signal stack.
Fixes: a942476236b5 ("Cygwin: sigdelayed: pop return address from signal stack earlier")
Co-authored-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
When a signal handler is called via sigdelayed, sigdelayed pops
the original address to return to from the signal stack. It only
does so after the signal handler has been called and returned.
If the signal handler never returns, for instance because it calls
longjmp or setcontext, the address stays on the signal stack and
the stack loses one slot. Given the stack has a depth of 256 entries,
no signal handler will be called after 256 signal handlers long
jumping out.
Pop the return address from the signal stack prior to calling the
signal handler and store it in a callee-saved register. This avoids
filling up the signal stack in a scenario like this.
Addresses: https://cygwin.com/pipermail/cygwin/2025-March/257648.html
Fixes: 61522196c715 ("* Merge in cygwin-64bit-branch.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
There seems to be no rationale reason for _cygtls::spinning to exist,
so it has been removed. _cygtls::spinning was introduced in the commit
edc4f86ad282A, and this flag means that another thread is waiting to
acquire _cygtls::stacklock. It is checked in the sig thread in _cygtls::
interrupt_now(), and if spinning is true, the interrupt will be delayed.
However, in this case, _cygtls::incyg is also set, so it is supposed to
be covered by _cygtls::incyg flag and does not seem to add any value.
If some problems happen in the signal handling, it might be a good idea
to revert this commit and check if the issue will be fixed.
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
|
|
Per the comment in _cygtls::interrupt_now(), the spinning flag
is supposed to guard that the targeted thread is about to enter
the Cygwin DLL. Setting spinning has then been added to _sigfe,
_sigbe, sigdelayed and stabilize_sig_stack, the latter being called
from setjmp/longjmp.
However, setjmp/longjmp only enter the DLL in case of a pending
signal, calling _cygtls::call_signal_handler(). This in turn is
already guarded by setting the incyg flag, and there's no other
action in stabilize_sig_stack which might interfere with the
signal setup. All the rest of setjmp/longjmp is plain userspace.
Therefore, drop setting the spinning flag from stabilize_sig_stack,
because it results in dropped signals in tight longjmp loops.
Fixes: edc4f86ad2827 ("* Makefile.in (clean): Remove sigfe.s.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Commit 0b6fbd396ca2f ("* exceptions.cc (_cygtls::interrupt_now): Revert
to checking for "spinning" when choosing to defer signal.") introduced
a bug in the loop inside the stabilize_sig_stack subroutine:
First, stabilize_sig_stack grabs the stacklock. The _cygtls::incyg
flag is then incremented before checking if a signal has to be handled
for the current thread.
If no signal waits, the code simply jumps out, decrements _cygtls::incyg
and returns to the caller, which eventually releases the stacklock.
However, if a signal is waiting, stabilize_sig_stack releases the
stacklock, calls _cygtls::call_signal_handler(), and returns to
the start of the subroutine, trying to grab the lock.
After grabbing the lock, it increments _cygtls::incyg... wait...
again?
The loop does not decrement _cygtls::incyg after
_cygtls::call_signal_handler(), which returns with _cygtls::incyg
set to 1. So it increments incyg to 2. If no other signal is
waiting, stabilize_sig_stack jumps out and decrements _cygtls::incyg
to 1. Eventually, setjmp or longjmp both will return to user
code with _cygtls::incyg set to 1. This *may* be fixed at some later
point when signals arrive, but there will be a time when the application
runs in user code with broken signal handling.
Fixes: 0b6fbd396ca2f ("* exceptions.cc (_cygtls::interrupt_now): Revert to checking for "spinning" when choosing to defer signal.")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
This patch calls Sleep(0) in the wait loop in lock() to increase the
chance of being unlocked in other threads. The lock(), unlock() and
locked() are moved from sigfe.s to cygtls.h so that allows inline
expansion.
Addresses: https://cygwin.com/pipermail/cygwin/2024-November/256744.html
Fixes: 61522196c715 ("* Merge in cygwin-64bit-branch.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
|
|
The currently handled signal in a thread is called _cygtls::sig.
The variable name "sig" is used pretty often in the Cygwin source.
This makes it tricky to distinguish the currently handled signal
from any other usage of "sig".
Therefore, rename _cygtls::sig to _cygtls::current_sig
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Various forms of describing what we do with the stacklock are
used. Try to be consistent.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Previously, sigfe had a bug that the signal handler destroys fpu state.
This is caused by fninit instruction in sigdelayed. With this patch,
saving/restoring the FPU/SIMD state is done using fxsave/fxrstor or
xsave/xrstor rather than fnstcw/fldcw, stmxcsr/ldmxcsr and push/pop
xmm0-xmm15. Since xsave/xrstor is used, not only x87/MMX/SSE states
but also AVX/AVX2/AVX-512 states can be maintained unlike before.
Addresses: https://cygwin.com/pipermail/cygwin/2024-October/256503.html
Fixes: ed89fbc3ff11 ("* gendef (sigdelayed (x86_64)): Save and restore FPU control word.")
Reported-by: Christian Franke <Christian.Franke@t-online.de>
Suggested-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
|
|
On Linux, __progname and program_invocation_short_name are just
different exported names of the same string. Do the same in Cygwin.
This requires to tweak the mkglobals_h so as not to touch the
EXPORT_ALIAS expression. Also, use the base variable
program_invocation_short_name throughout. __progname is just
the export for getopt.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
If specified, set version timestamp to this value.
Enable deterministic archives for ar and ranlib.
Set cygwin1.dll PE and export table header timestamps to zero.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
|
|
Since 4e7817498efc, we're just running the tests against the installed
DLL. We're arranging to put the build directory on the path, but since
it doesn't contain cygwin1.dll (since it's built with a different name
and renamed on installation), that doesn't have any effect.
Arrange to place the just-built DLL into a directory which the testsuite
can place on it's path (while running the test, but not while compiling
it).
Also fix any remaining references to cygwin0.dll in testsuite,
documentation and comments.
Fixes: 4e7817498efc ("Cygwin: Makefile: Drop all the "test dll" considerations")
|
|
We're going to switch to regular test releases, rather than the
old, handcrafted snapshots method.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
A hang was encountered, apparently triggered by commit 63b503916d42,
changing tls_pathbufs from malloc'ed to HeapAlloc'ed memory. After
lengthy debugging it transpired that adding the heap handle to the
tls_pathbuf struct added 8 bytes to the cygtls area, thus moving
the "context" member by 8 bytes, too, so it was suddently unaligned.
Fix this for now by changing the alignment.
Fix this once and for all, by adding code to the gentls_offsets script
to check if the alignment of the "context" member is 16 bytes. If not,
print a matching error message, remove the just generated file, and exit
with error.
FIXME: It would be really nice to find a way to auomate the correct
alignment of the "context" member, but I don't see any way to use
alignment attributes to get what we need here.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Create subdirs and move files accordingly:
- DevDocs: doc files
- fhandler: fhandler sources, split fhandler.cc into base.cc and null.cc
- local_includes: local include files
- scripts: scripts called during build
- sec: security sources
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
