Define FD_SETSIZE (<sys/select.h>) to be 1024 by default, and define
NOFILE (<sys/param.h>) to be OPEN_MAX (== 3200) by default.
Remove the comment in <sys/select.h> that FD_SETSIZE should be >=
NOFILE.
Bump API minor.
Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html
- With this patch, the empty path (empty element in PATH or PATH is
absent) is treated as the current directory as Linux does. This
feature is added for Linux compatibility, but it is deprecated.
POSIX notes that a conforming application shall use an explicit
pathname to specify the current working directory.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html
This reverts commit 1f8f7e2d54, "* libc/stdio/refill.c (__srefill):
Try again after EOF on Cygwin." If EOF is set on a file, the stdio
input functions will now immediately return EOF rather than trying
again to read. This aligns Cygwin's behavior to that of Linux.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html
- poll() has a bug that it returns event which is not inquired if
events are inquired in multiple pollfd entries on the same fd at
the same time. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251732.html
- Currently, ENABLE_VIRTUAL_TERMINAL_PROCESSING flag is disabled
unconditionally when exiting from cygwin. This causes ANSI escape
sequence disabled in Windows Terminal where it is enables by
default. This patch retains that flag if it is originally enabled.
Commit e1ce752a1d, "Cygwin: remove miscellaneous 32-bit code", removed
most occurrences of '#ifdef __x86_64__'. Restore those occurrences
that guarded code specific to the AMD64 processor, and #error out if
the processor is different. This will make it easier to find
AMD64-specific code if we ever want to add support for a different
64-bit processor (e.g., ARM64).
The _REENT_GLOBAL_STDIO_STREAMS was introduced by commit
668a4c8722 in 2017. Since then it was enabled by
default for RTEMS. Recently, the option was enabled for Cygwin which
previously used an alternative implementation to use global stdio streams.
In Newlib, the stdio streams are defined to thread-specific pointers
_reent::_stdin, _reent::_stdout and _reent::_stderr. If the option is disabled
(the default for most systems), then these pointers are initialized to
thread-specific FILE objects which use file descriptors 0, 1, and 2,
respectively. There are at least three problems with this:
(1) The thread-specific FILE objects are closed by _reclaim_reent(). This
leads to problems with language run-time libraries that provide wrappers to
the C/POSIX stdio streams (for example C++ and Ada), since they use the
thread-specific FILE objects of the initialization thread. In case the
initialization thread is deleted, then they use freed memory.
(2) Since thread-specific FILE objects are used with a common output device via
file descriptors 0, 1 and 2, the locking at FILE object level cannot ensure
atomicity of the output, e.g. a call to printf().
(3) There are resource managment issues, see:
https://sourceware.org/pipermail/newlib/2022/019558.htmlhttps://bugs.linaro.org/show_bug.cgi?id=5841
This patch enables the _REENT_GLOBAL_STDIO_STREAMS behaviour for all Newlib
configurations and removes the option. This removes a couple of #ifdef blocks.
Cygwin tool ssp generates gmon.out files with different address
resolution than other tools do. Two address bytes per bucket rather than
the usual four address bytes. Gprof can deal with the difference but
gmondump can't because the latter's gmon.out header validation fails.
- Remove the offending portion of the header validation code.
- Make sure all code can handle differing address resolutions.
- Display address resolution in verbose data dumps.
- Change "rawarc" to "struct rawarc" in certain sizeof expressions to
avoid buffer overrun faults.
- When "-v" (verbose) is specified, note when there is missing bucket
data or rawarc data.
In the previous commit, __stdcall was removed from _dll_crt0 in
winsup.h and dcrt0.cc but not in lib/cygwin_crt0.c. For consistency,
restore the first two occurrences of __stdcall. We could instead
remove it from the declaration in lib/cygwin_crt0.c, but this might
appear to affect binary compatibility, even though it really doesn't.
These have no effect on x86_64. Retain a few occurrences of __cdecl
in files imported from other sources.
Also retain all occurrences of WINAPI, even though the latter is
simply a macro that expands to __stdcall. Most of these occurrences
are associated with Windows API functions, and removing them might
make the code confusing instead of simpler.
Link directly with RegDeleteKeyExW(), available since Vista.
(It's unclear the LoadLibrary wrapper was ever doing anything useful
here, as (i) DLL lookup in PATH was avoided as advapi32 is already
loaded into the process, and (ii) advapi32 is a 'known DLL' which is
only ever loaded from system directory)
Remove "32" or "64" from each of the following names: acl32,
aclcheck32, aclfrommode32, aclfrompbits32, aclfromtext32, aclsort32,
acltomode32, acltopbits32, acltotext32, facl32, fchown32, fcntl64,
fstat64, _fstat64, _fstat64_r, ftruncate64, getgid32, getgrent32,
getgrgid32, getgrnam32, getgroups32, getpwuid32, getpwuid_r32,
getuid32, getuid32, initgroups32, lseek64, lstat64, mknod32, mmap64,
setegid32, seteuid32, setgid32, setgroups32, setregid32, setreuid32,
setuid32, stat64, _stat64_r, truncate64.
Remove prototypes and macro definitions of these names.
Remove "#ifndef __INSIDE_CYGWIN__" from some headers so that the new
names will be available when compiling Cygwin.
Remove aliases that are no longer needed.
Include <unistd.h> in fhandler_clipboard.cc for the declarations of
geteuid and getegid.
Remove the definitions of the following: acl, aclcheck, aclfrommode,
aclfrompbits, aclfromtext, aclsort, acltomode, acltopbits, acltotext,
chown, fchown, _fcntl, fstat, _fstat_r, ftruncate, getegid, geteuid, getgid,
getgrent, getgrgid, getgrnam, getgroups, getpwduid, getpwuid,
getpwuid_r, getuid, initgroups, lacl, lacl32, lchown, lseek, lstat,
mknod, mmap, setegid, seteuid, setgid, setgroups, setregid, setreuid,
setuid, stat, _stat_r, truncate.
[For most of these, the corresponding 64-bit entry points are obtained
by exporting aliases. For example, acl is an alias for acl32, and
truncate is an alias for truncate64.]
Remove the following structs and all code using them (which is 32-bit
only): __stat32, __group16, __flock32, __aclent16_t.
Remove the typedefs of __blkcnt32_t __dev16_t, __ino32_t, which are
used only in code that has been removed.
Put the typedefs of __uid16_t and __gid16_t in one header, instead of
one header if __INSIDE_CYGWIN__ is defined and a different header
otherwise.
The current definition of mknod in syscalls.cc has a third argument of
type __dev16_t instead of dev_t. Fix this on 64-bit Cygwin by making
the existing mknod 32-bit only and then exporting mknod as an alias
for mknod32. (No fix is needed on 32-bit because mknod is redirected
to mknod32 via NEW_FUNCTIONS in Makefile.am.)
Addresses: https://cygwin.com/pipermail/cygwin-developers/2022-May/012589.html
killpg(pgid, 0) (or kill_pgrp(pgid, si_signo=0), in signal.cc)
fails (returns -1) even when there is a process in the process
group pgid, if the process is in the middle of spawnve(), see
https://cygwin.com/pipermail/cygwin/2022-May/251479.html
When exec'ing a process the assumption is that the exec'ed process creates its
own symlink (in pinfo::thisproc() in pinfo.cc). If the exec'ing process
calls NtClose on it's own winpid symlink, but the exec'ed process didn't
progress enough into initialization, there's a slim chance that neither
the exec'ing process, nor the exec'ed process has a winpid symlink
attached.
Always create the winpid symlink in spawn.cc, even for exec'ed Cygwin
processes. Make sure to dup the handle into the new process, and stop
creating the winpid symlink in exec'ed processes.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- The commit "Cygwin: fix new sigfe.o generation in optimized case"
fixed the wrong tlsoffsets generation by adding -O0 to compile
options. Current gentls_offsets expects entry of "start_offset"
is the first entry in the assembler code. However, without -O0,
entry of "start_offset" goes to the last entry for some reason.
Currently, -O0 can prevents assembler code from reversing the
order of the entries, however, there is no guarantee that it will
retain the order of the entries in the future.
This patch makes gentls_offsets parse the assembler code in the
two pass to omit -O0 option dependency.
Leave x86_64 CPU-specific code and #error out when trying to build
for another target. Access special registers CPU-agnostic.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Previously, the command "cmd /c script -c cmd" in console of Win7
crashes. This seems to be due to a bug (?) of AttachConsole().
This patch adds workaround for this issue.
Currently, pty reattaches to the console of the process which is
predetermined by ConsoleProcessList() after temporarily attaching
to another console. After that, the console output handle opened
with the name "CONOUT$" may not be accessible in Win7.
This seems to happen when the attached process does not have the
same handle even if the console attached is the same. With this
patch, cygwin-console-helper which is started when pty master is
opened in console, is utilized to be a target process to which
pty reattaches if the OS is Win7.
Commit 0597c84b9b ("Cygwin: revamp TLS offsets computation")
introduced a really weird problem when building Cygwin with
optimization.
First of all, the tlsoffsets file is broken with -O2. This
can easily be fixed by running the compiler with -O0 when called
from the gentls_offsets script.
But it gets worse:
When creating sigfe.o with optimization, the generated machine code
uses incorrect offsets: For some reason the assembler codes using
_cygtls.stackptr as offset value are assembled into machine code
using _cygtls.pstackptr as offsets.
And as if that isn't already absurd enough, renaming _cygtls.pstackptr
to, say, _cygtls.blurb, fixes the assembled machine code expressions;
they use the value of _cygtls.stackptr again.
So I changed gentls_offsets and gendef to use _cygtls.foo_p rather
than _cygtls.pfoo and that fixes the assembled code in the optimized
case.
No, I can't explain that. There's no system in that behaviour.
It looks absolutely crazy.
Fixes: 0597c84b9b ("Cygwin: revamp TLS offsets computation")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Given we only called create_token on W7 WOW64 anyway, we can now
drop this function and all other functions only called from there
entirely.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Takashi Yano
Ken Brown
Christian Franke
Sebastian Huber
Mark Geisert
Jon Turney
Brian Inglis
Corinna Vinschen