Originally the code was written to allow three ways of prefixing
accounts and to freely define a domain/account separator. This code
has been disabled even before being officially released, and it was
never re-enabled. Given there has been no complaints for eight years
now, drop this code eventually. Just add a macro to define the
domain/account separator statically.
Fixes: cc332c9e27 ("(cygheap_pwdgrp::nss_init_line): Disable db_prefix
and db_separator settings. Add comment")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This is a long-standing thinko.
When you exec a process, dll_crt0_0 in the child process calls
child_info_spawn::handle_spawn(). handle_spawn() initialises the
cygheap.
Now consider calling strace. Strace is a non-Cygwin process dynamically
loading cygwin1.dll via LoadLibrary. This in turn initializes the DLL:
- dll_crt0_0 finds that the process it attaches to has been exec'd, so
child_info_spawn::handle_spawn() is called.
- If the DLL is being dynamically loaded, handle_spawn() calls
child_info_spawn::get_parent_handle(). This in turn tries to set
the moreinfo->myself_pinfo value inside the cygheap to NULL.
- However, at this time, the cygheap has not yet been initialized. This
only occurs in the cygheap_fixup_in_child() call after get_parent_handle()
returns.
--> SEGV
This thinko never had a negative side effect, because the cygheap was
pre-allocated at DLL load time until commit 2f9b8ff00c ("Cygwin:
decouple cygheap from Cygwin DLL"). With 2f9b8ff00c, the cygheap
actually doesn't exist until after the call to cygheap_fixup_in_child().
Fix this problem by moving the assignment after the call to
cygheap_fixup_in_child().
Fixes: 3de7be4c1d ("* DevNotes: Add entry cgf-000007. [...]")
Fixes: 2f9b8ff00c ("Cygwin: decouple cygheap from Cygwin DLL")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
After decoupling cygheap from the DLL loading address, the check
for a different _cygheap_start has gone. So the matching string
check in multiple_cygwin_problem is obsolete now.
Fixes: 2f9b8ff00c ("Cygwin: decouple cygheap from Cygwin DLL")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
In commit 2dab880c96 I did a mistake when
I copied the new fhandler_serial::switch_modem_lines() from my modified
3.3.6 branch to the current master and I left a copy paste error. This
patch fixes that error.
Fixes: 2dab880c96 ("Cygwin: fix TIOCMBIS/TIOCMBIC not working when using usbser.sys")
- Previously, we have two tty.cc, one is winsup/cygwin/tty.cc and
the other is winsup/cygwin/fhandler/tty.cc. This is somewhat
confusing. This patch renames fhandler/tty.cc to fhandler/pty.cc.
When creating regular Cygwin test releases we need a way to
automate unambiguous version information based on the output
of `git describe'. Allow to inject a release string via a
preprocessor macro CYGPORT__RELEASE_INFO. Change the default
release info to recognize a local, non-distro build.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
We're going to switch to regular test releases, rather than the
old, handcrafted snapshots method.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Call __builtin_gcn_get_stack_limit and __builtin_gcn_first_call_this_thread_p
to reduce dependency on some register/layout assumptions by using the new
GCC mainline (GCC 13) builtins, if they are available. If not, the existing
code is used.
- The codes related to pty and console in spawn.cc have been moved
into the new class fhandler_termios::spawn_worker, and make spawn.cc
call them. The functionality has not been changed at all.
During 'make man', makedocbook falsely reports "texinfo command
'@modifier' remains in output" while processing the setlocal(3) manpage,
which contains that literal string.
Move the check for unrecognized texinfo commands to before processing
'@@' (an escaped '@') in the texinfo source, and teach it to ignore
them.
Improve that check slightly, so it catches non-alphabetic texinfo
commands, of which there are few.
Now we don't have false positives, we can make unrecognized texinfo
commands fatal to manpage generation, rather than leaving them verbatim
in the generated manpage.
In winsup/cygwin/fhandler/serial.cc, the function
fhandler_serial::switch_modem_lines() is called when TIOCMBIS/TIOCMBIC
are used in an ioctl() call.
This function uses EscapeCommFunction() for setting and resetting RTS
and DTR signals of a serial port. Unfortunately, this function does not
work on USB CDC devices.
This is not a true bug of CYGWIN but an issue of the usbser.sys driver,
from Windows 2000 to the latest Windows 11. Both 32bit and 64bit
versions of the operating system are affected. Actually, I tested
EscapeCommFunction() also when using a real UART, based on the
traditional 16550 driver and it works fine. Using thirdy party CDC
drivers, like the one provided by FTDI for their USB bridge chips,
probably also works.
However, it is also possible to drive the RTS/DTR signals by writing
their state with SetCommState(), which proved to be working fine all
types of connection. This is also a better solution for handling these
signals since RTS/DTR can be set at the same time rather than having two
separate calls with a visible delay between them.
Report 0 instead of 268435455 (i.e. 0xFFFFFFF) in the tty field of
/proc/*/stat for processes without a controlling terminal. This is what
the procps utility expects when selecting or excluding such processes.
..., not just '#if defined(__CYGWIN__)'. (Exception: 'clog10l' which currently
indeed is for Cygwin only.)
This completes 2017-07-05 commit be3ca39474
"Fixed warnings for some long double complex methods" after Aditya Upadhyay's
work on importing "Long double complex methods" from NetBSD.
For example, this changes GCC/nvptx libgfortran 'configure' output as follows:
[...]
checking for ccosf... yes
checking for ccos... yes
checking for ccosl... [-no-]{+yes+}
[...]
..., and correspondingly GCC/nvptx 'nvptx-none/libgfortran/config.h' as
follows:
[...]
/* Define to 1 if you have the `ccosl' function. */
-/* #undef HAVE_CCOSL */
+#define HAVE_CCOSL 1
[...]
Similarly for 'ccoshl', 'cexpl', 'cpowl', 'csinl', 'csinhl', 'ctanl', 'ctanhl',
'cacoshl', 'cacosl', 'casinhl', 'catanhl'. ('conjl', 'cprojl' are not
currently being used in libgfortran.)
This in turn simplifies GCC/nvptx 'libgfortran/intrinsics/c99_functions.c'
compilation such that this files doesn't have to provide its own
"Implementation of various C99 functions" for those, when in fact they're
available in newlib libm.
Commit 737e2004a3 accidentally introduced a call to strlen in
code used with wide character strings in case of wcsftime. Use
STRLEN instead.
Fixes: 737e2004a3 ("strftime.c(__strftime): add %q, %v, tests; tweak %Z doc")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Drop 'makedocbook --cache' (any dependency on the man-cache rule which
invokes that was dropped by the non-recursive make changes)
Instead, add some explicit locking which prevents processes colliding
over the file containing generated python code for the parser table.
This adds an extra section to the stackdump, which lists the loaded
modules and their base address. This is perhaps useful as it makes it
immediately clear if RandomCrashInjectedDll.dll is loaded...
Future work: It seems like the 'InMemoryOrder' part of
'InMemoryOrderModuleList' is a lie?
> Loaded modules
> 000100400000 segv-test.exe
> 7FFF2AC30000 ntdll.dll
> 7FFF29050000 KERNEL32.DLL
> 7FFF28800000 KERNELBASE.dll
> 000180040000 cygwin1.dll
> 7FFF28FA0000 advapi32.dll
> 7FFF29F20000 msvcrt.dll
> 7FFF299E0000 sechost.dll
> 7FFF29B30000 RPCRT4.dll
> 7FFF27C10000 CRYPTBASE.DLL
> 7FFF28770000 bcryptPrimitives.dll
This adds an additional column to the stack trace in a .stackdump file,
which gives the stack frame return address as a module name+offset. This
makes it a possible to convert the address to a function name without
having to guess what module the address belongs to.
> Stack trace:
> Frame Function Args
> 0007FFFFCC30 0001004010E9 (000180048055, 000180046FA0, 000000000002, 00018031E160) segv-test.exe+0x10E9
> 0007FFFFCD30 0001800480C1 (000000000000, 000000000000, 000000000000, 000000000000) cygwin1.dll+0x80C1
> 0007FFFFFFF0 000180045C86 (000000000000, 000000000000, 000000000000, 000000000000) cygwin1.dll+0x5C86
> 0007FFFFFFF0 000180045D34 (000000000000, 000000000000, 000000000000, 000000000000) cygwin1.dll+0x5D34
> End of stack trace
Loosely based on this patch [1] by Brian Dessent.
[1] https://cygwin.com/pipermail/cygwin-patches/2008q1/006306.html
Every time the cygheap is initialized, that is, on each fork
or exec, cygheap_init() *again* computes the bucket size values
and stores them in the cgyheap, albeit they are always the
same values anyway.
Make bucket_val a local const array, statically initialized
instead.
Fixes: 61522196c7 ("* Merge in cygwin-64bit-branch.)"
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Now that the cygheap isn't part of the CYgwin DLL anymore, we have a
known memory location which is not known in maps output. Fix that by
checking for cygheap address (same in all processes) and add to output.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
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: e1254add73 ("Cygwin: Allow accessing 48 bit address space in Windows 8.1 or later")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The first attempt to support the 64-bit mode had two bugs:
1. The saved general-purpose register 31 value was overwritten with the saved
link register value.
2. The link register was saved and restored using 32-bit instructions.
Use 64-bit store/load instructions to save/restore the link register. Make
sure that the general-purpose register 31 and the link register storage areas
do not overlap.
.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 7589034cc3.
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>
> ERROR: xref linking to Stubs has no generated link text.
> Error: no ID for constraint linkend: Stubs.
(Despite saying "ERROR", this is actually a warning, and manpages are
still generated)
Improve chapter-texi2docbook so it generates elements for texinfo
sections as well, so that a cross-reference to the "Stubs" section
contains a valid element ID.
Corinna Vinschen
Carlo Bramini
Jon Turney
Takashi Yano
Tobias Burnus
Sebastian Huber
Andy Koppe
Thomas Schwinge
Hamish McIntyre-Bhatty