Previously, the console device could not be accessed from other terminals.
Due to this limitation, GNU screen and tmux cannot be opened in console.
With this patch, console device can be accessed from other TTYs, such as
other consoles or ptys. Thanks to this patch, screen and tmux get working
in console.
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
The devices /dev/conin,conout,console were wrongly visible from ptys,
though they are inaccessible. This is because fhandler_console::exists()
returns true due to existing invisible console. This patch makes these
devices invisible from ptys.
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
POSIX states "A terminal may be the controlling terminal for at most
one session."
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html
However, in cygwin, multiple sessions could be associated with the
same TTY. This patch aligns CTTY behavior to the statement of POSIX.
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
... so that all of 'exit', '_exit', '_Exit' work. 'exit' thus becomes the
standard 'newlib/libc/stdlib/exit.c' -- and functions registered via 'atexit'
are now called at return from 'main' or manual 'exit' invocation.
https://cygwin.com/pipermail/cygwin/2022-December/252737.html
If the less is started from non-cygwin shell and window size is
changed, it will hang-up when quitting. The cause of the proglem is
that less uses longjump() in signal handler. If the signal handler
is called while cygwin is acquiring the mutex, cygwin loses the
chance to release mutex. With this patch, the mutex is released
just before calling kill_pgrp() and re-acquired when kill_pgrp()
returns.
Reported-by: Gregory Mason <grmason@epic.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
After 90236c3a2c, the testsuite is failing, as the cygwin0.dll
referenced by the implib that testsuite programs are linked with doesn't
exist anymore.
We don't need to make and link the testsuite with a specially named DLL,
as the cygwin DLL (since 526b0fbca3) takes into consideration the path
it's executing from to define separate "Cygwin installations", which
don't interact.
Fixes: 90236c3a2c ("Cygwin: Makefile: build new-cygwin1.dll in a single step")
Commit c1023ee353 introduced a split between mount flags and
path flags. It didn't initialize symlink_info::path_flags in
path_conv::check, because that's done in symlink_info::check.
However, there are two code paths expecting symlink_info::path_flags
being already initialized and both skip symlink_info::check.
Make sure symlink_info::path_flags is initalized to 0 early in
path_conv::check.
Fixes: c1023ee353 ("Cygwin: path_conv: decouple path_types from mount types")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Rather than guessing, based on just the presence of libbfd, add an
explicit configuration option, to build dumper or not, defaulting to
building it.
This might have some use when bootstrapping Cygwin for a new
architecture, or when building your own Cygwin-targetted cross-compiler,
rather than installing one from the copr, along with the dependencies of
libbfd.
Tweak slightly to allow implementing entire {w}mem{p}{cpy,move}
family:
Add WIDE macro processing for wmem* and POST macro processing for
memp* functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Since no other port uses this custom libgloss multi-build.in logic,
and it's making things difficult to unify, drop it all. The set of
installed objects and their content should be the same.
There is a difference in the builds: currently we compile all the
objects in this subdir twice, but only a subset of them use a diff
set of flags, and are actually installed (the librdimon.a and its
objects). So this change speeds things up by removing the duplicate
compilation.
There is a short term cost in having to duplicate the compile rules
for the files that are different, but this is minor when compared to
being able to delete the unused multi-build logic (which we'll do in
a sep commit), and we'll be able to clean this up when we move the
code to unified automake.
None of this should be confused with the common multilib logic.
This is *multi-build* which is processed in parallel.
This logic looks like it was copied from the arm port, but it isn't
actually used here. Since no other port uses this custom libgloss
multi-build.in logic, and it's making things difficult to unify,
and aarch64 isn't even using it, drop it all. The set of installed
objects and their content should be the same.
Once we move this to unified automake, if we want to readd support
for subdir multi-builds, it'll be a lot easier as we can just add
another set of objects with custom flags.
None of this should be confused with the common multilib logic.
This *multi-build* which is processed in parallel.
It seems there is a swapped logic in one of the subcases of
setjmp.S for MIPS: when the FPU registers are 64-bit within
a 32-bit aligned jmp_buf, the code realigns the pointers
before doing 64-bit writes, but the branch logic is swapped:
we must avoid the address adjustement when bit 2 is zero
(that is, the address is already 8-byte aligned).
This always triggers an address error when run, as tested
on a MIPS VR4300 with O64 ABI.
The implementation of expf() explains how approximation in the range [0 - 0.34] is done. The comment describes the "Reme" algorithm for constructing the polynomial. This is a typo and should be the "Remez" algorithm. The remez algorithm (or minimax) is used to calculate the coefficients of polynomials in other implementations of exp(0 and log().
See more:
https://en.wikipedia.org/wiki/Remez_algorithm
This implements a set of vectorized math routines to be used by the
compiler auto-vectorizer. Versions for vectors with 2 lanes up to
64 lanes (in powers of 2) are provided.
These routines are based on the scalar versions of the math routines in
libm/common, libm/math and libm/mathfp. They make extensive use of the GCC
C vector extensions and GCN-specific builtins in GCC.
As per the arm Procedure Call Standard for the Arm Architecture
section 6.1.2 [1], VFP registers s16-s31 (d8-d15, q4-q7) must be
preserved across subroutine calls.
The current setjmp/longjmp implementations preserve only the core
registers, with the jump buffer size too small to store the required
co-processor registers.
In accordance with the C Library ABI for the Arm Architecture
section 6.11 [2], this patch sets _JBTYPE to long long adjusting
_JBLEN to 20.
It also emits vfp load/store instructions depending on architectural
support, predicated at compile time on ACLE feature-test macros.
[1] https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
[2] https://github.com/ARM-software/abi-aa/blob/main/clibabi32/clibabi32.rst
The complicated build routine was only required because we needed
the .cygheap section at the end of the file, and the debug sections
broke this. Now that the cygheap is out of the way, we really don't
have to do this anymore, and the build can just generate a DLL with
integrated debug info.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Make sure to create a new cygwin_version.c if it either doesn't
exist yet, or if it would be different from the former file.
This avoids unnecessary DLL rebuilding.
Fixes: 97eb64b909 ("Cygwin: uname: generate default release string from git as well")
Fixes: 4949a82cde ("Cygwin: uname: fix building in non-git source dir")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
We have "Iconv" and "iconv" nodes which generates Iconv.html and
iconv.html files. On a case-insensitive filesystem, these collide.
Rename the "Iconv" node to match the chapter name that it's already
using to avoid the issue.
Move the drive substitution code after the call to
GetFinalPathNameByHandleW into a local function revert_virtual_drive
and add code to handle non-remote virtual drives, i. e., those
created with the subst command. (Try to) make sure that virtual
drives are never treated like symlinks.
Fixes: 19d59ce75d ("Cygwin: path_conv: Rework handling native symlinks as inner path components")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
https://cygwin.com/pipermail/cygwin/2022-December/252628.html
After the commit 9e4d308cd5, the performance of read from non-cygwin
pipe has been degraded. This is because select_sem mechanism does not
work for non-cygwin pipe. This patch fixes the issue.
Fixes: 9e4d308cd5 ("Cygwin: pipe: Adopt FILE_SYNCHRONOUS_IO_NONALERT
flag for read pipe.")
Reported-by: tryandbuy <tryandbuy@proton.me>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we
were using the type __sFILE64 even for 64 bit. That was lazy and wrong.
so commit 2902b3a09e ("Cygwin: drop requirement to build newlib's
stdio64") tried to fix that.
Unfortunately this patch forgot to take the exposure of the typename
__sFILE64 in userspace into account. This leads to trouble in C++ due
to name mangling.
Commit 0f376ae220 tried to fix this by just renaming __sFILE to
__sFILE64 by using a macro. While __sFILE and __sFILE64 are the same
size, they are not exactly congruent.
To avoid backward compatibility problems, make sure to define FILE
as the real __sFILE64, and make sure that __sFILE is not defined at
all on Cygwin.
Fixes: 0f376ae220 ("Cygwin: rename __sFILE to __sFILE64 for backward
compatibility")
Fixes: 2902b3a09e ("Cygwin: drop requirement to build newlib's stdio64")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we
were using the type __sFILE64 even for 64 bit. That was lazy and wrong.
so commit 2902b3a09e ("Cygwin: drop requirement to build newlib's
stdio64") tried to fix that.
Unfortunately this patch forgot to take the exposure of the typename
__sFILE64 in userspace into account. This leads to trouble in C++ due
to name mangling.
Fix this by redefining __sFILE to __sFILE64. The type name is very much
internal, so it doesn't really matter, except for the fact that it needs
to stay backward compatible so as not to break building against C++ libs
built under older versions of Cygwin.
Fixes: 2902b3a09e ("Cygwin: drop requirement to build newlib's stdio64")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
commit 97eb64b909 broke building outside of a git dir, because
the git describe command would fail. Fix this by checking if
we're in a git tree at all and just generate an empty string
as version string. Use this in uname_x to generate a fallback
version.
Fixes: 97eb64b909 ("Cygwin: uname: generate default release
string from git as well"
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When building a release with cygport, we get uname version info
from cygport, which in turn gets version info from `git describe'.
During development, the release info for local builds was not
that helpful yet. Fix that, by creating version info from
`git describe' if CYGPORT_RELEASE_INFO isn't given. Make sure to
always force rebuild of the version info to pick up source file
changes as well as git actions.
Rearrange code slightly to generate machine info first, release info
after that. Use snprintf to generate release string safely.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Takashi Yano
Thomas Schwinge
Mike Frysinger
Jon Turney
Corinna Vinschen
Victor L. Do Nascimento
Giovanni Bajo
Jeff Johnston
Nadav Rotem
Kwok Cheung Yeung