Prior to 591fec858d01 ("Cygwin: decouple cygheap from Cygwin DLL")
the .cygheap section was required to stay the last section in the
final binary. That required some juggling with objcopy to make
sure the .gnu_debuglink section is prior to the .cygheap section
in the final DLL.
This isn't required anymore, so just drop it.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Another reason ASLR may fail is the coupling of the standard shared
mem regions (global, userinfo, process info, shared console) to the
address of the Cygwin DLL. They are always placed in fixed addresses
preceeding the Cygwin DLL's address. With ASLR this is bound to fail.
Use a fixed, unused memory area to place the shared mem regions.
This also allows to simplify the shared memory creation. There's
no reason anymore to rebase the regions and rather than offsets,
just use the addresses directly.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
One reason that ASLR is tricky is the fact that the cygheap
is placed at the end of the DLL and especially that it's expected
to be growable. To support ASLR, this construct must go.
Define dedicated cygheap memory region and reserve entire region.
Commit 3 Megs, as was the default size of the cygheap before.
Fix linker script accordingly, drop a now useless version check
in get_cygwin_startup_info().
Collect all info about memory layout in one header file, so
the mem layout is documented in one logical place and not
in heap.cc arbitrarily.
Use info from this file throughout.
This is to prepare for ASLR support.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Exception handling was *still* printing addresses as 44 bit values,
but Windows supports a 48 bit virtual address space since Windows
8.1. Fix that.
Fixes: e1254add73b1 ("Cygwin: Allow accessing 48 bit address space in Windows 8.1 or later")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
.com is a remnant from the past. There are only five executables
left:
chcp.com
format.com
mode.com
more.com
tree.com
Calling them on the command line already requires to use the
suffix anyway. So drop useless .com test from the execve test
for scripts (they are handled earlier in the same function
as executables) and do not handle them like .exe suffixes in
other functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This reverts commit 7589034cc3151bfac8cc3d3af5e91402a78e160b.
The previous commit 14816de9af69 ("Cygwin: spawn: drop special handling
for cmd.exe and command.com") make this patch unnecessary. The filename
argument (i. e., run_path in the caller) is now always non-NULL.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Apparently at one point handling cmd.exe and command.com special
made sense, but what that should be has never been documented.
There's also no clear reason why cmd.exe is different from any
other native executable. Additionaly, checking for command.com
is entirely useless on 64 bit Windows anyway.
Just drop this code.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- If the command executed is 'cmd.exe /c [...]', runpath in spawn.cc
will be NULL. In this case, is_console_app(runpath) check causes
access violation. This case also the command executed is obviously
console app., therefore, treat it as console app to fix this issue.
Addresses: https://github.com/msys2/msys2-runtime/issues/108
According to POSIX and the Linux man page, select(2) is supposed to
report read ready if a file is at EOF. In the case of a FIFO, this
means that the pipe is empty and there are no writers. But there
seems to be an undocumented exception, observed on Linux and other
platforms: If no writer has ever been opened, then select(2) does not
report read ready. This can happen if a reader is opened with
O_NONBLOCK before any writers have opened.
This commit makes Cygwin consistent with those other platforms by
introducing a special EOF test, fhandler_fifo::select_hit_eof, which
returns false if there's never been a writer opened.
To implement this we use a new variable '_writer_opened' in the FIFO's
shared memory, which is set to 1 the first time a writer opens. New
methods writer_opened() and set_writer_opened() are used to test and
set this variable.
Addresses: https://cygwin.com/pipermail/cygwin/2022-September/252223.html
The patch fixing the alignment of _cygtls::context accidentally
pushed the desperate attempt to automate the alignment by using
another, non-working variation of attribute((aligned)). Drop it.
Fixes: dcab768cb93e ("Cygwin: cygtls: fix context alignment")
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>
while debugging a problem introduced in commit
63b503916d42 ("Cygwin: tls_pathbuf: Use Windows heap")
a hang in fork was encountered using the original implementation
of tls_pathbuf:
Using tmp_pathbuf inside the code block guarded by __malloc_trylock
may call malloc from tmp_pathbuf::w_get and thus trying to lock an
exclusive SRW lock recursively, which results in a deadlock.
Allocate a small SECURITY_ATTRIBUTES block on the stack rather than
allocating a 64K tmp_pathbuf. This avoids the potential malloc call.
Drop the __malloc_trylock call entirely. There must not be a malloc
call inside the frok::parent block guarded by __malloc_lock, and
just trying to lock is too dangerous inside fork while other threads
might actually chage the content of the heap. Additionally, add a
comment frowning on malloc usage inside tis code block.
Fixes: 44a79a6eca3d ("Cygwin: convert malloc lock to SRWLOCK")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rather than using malloc/free for the buffers, we're now using
HeapAlloc/HeapFree on a HEAP_NO_SERIALIZE heap created for this
thread.
Advantages:
- Less contention. Our malloc/free doesn't scale well in
multithreaded scenarios
- Even faster heap allocation by using a non serialized heap.
- Internal, local, temporary data not cluttering the user heap.
- Internal, local, temporary data not copied over to child process
at fork().
Disadvantage:
- A forked process has to start allocating temporary buffers from
scratch. However, this should be alleviated by the fact that
buffer allocation usually reaches its peak very early in process
runtime, so the longer the proceess runs, the less buffers have
to allocated, and, only few processes don't exec after fork
anyway.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
shmat may call shmget. shmget locks by itself as necessary,
so there's no reason to keep the lock active and recurse into
the lock. Use SRWLOCK and only lock as required.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far we use a single muto to guard three different datastructures
inside class authz_ctx: the authz HANDLE, the user context HANDLE
and the context cache list. Split the single muto into three
independent SRWLOCKs and guard all datastrcutures as necessary to
avoid thread contention.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The old technique was from a time when we had to reduce stack pressure
by moving 64K buffers elsewhere. It was implemented using a static
global buffer, guarded by a muto. However, that adds a lock which may
unnecessarily serialize threads.
Use Windows heap buffers per invocation instead. HeapAlloc/HeapFree are
pretty fast, scale nicely in multithreaded scenarios and don't serialize
threads unnecessarily.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This simple testcase:
locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
is sufficient to reproduce a crash in _newlocale_r. After the first call
to newlocale, `st' points to __C_locale, which is const. When using `st'
as locale base in the second call, _newlocale_r tries to set pointers
inside base to NULL. This is bad if base is __C_locale, obviously.
Add a test to avoid trying to overwrite pointer values inside base if
base is __C_locale.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This way, the sem API is all in the same place, even if the
underlying semaphore class is still in thread.cc.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rename CygwinCreateThread to create_posix_thread and move
from miscfuncs.cc to create_posix_thread.cc, inbcluding all
related functions. Analogue for the prototypes.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Currently it is possible for symlink_info::check to return -1 in case
we're searching for foo and find foo.lnk that is not a Cygwin symlink.
This contradicts the new meaning attached to a negative return value
in commit 19d59ce75d. Fix this by setting "res" to 0 at the beginning
of the main loop and not seting it to -1 later.
Also fix the commentary preceding the function definition to reflect
the current behavior.
Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252030.html
provide entire internal and external pthread API from inside the
same file.
While I dislike to have another even larger file, this is basically
cleaning up the source and grouping the external API into useful
chunks. Splitting the file cleanly is tricky due to usage of inline
methods is_good_object and verifyable_object_isvalid.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far, wmemset used the C implemantation from newlib. Let's use
the optimized assembler code instead.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
