- If a lot of mintty are started in a short time from a mintty, some
of them hang with empty screen, crash immediately or hang on exiting
mintty. The following report seems to be related to this issue.
https://cygwin.com/pipermail/cygwin/2020-August/245751.html
The cause is not clear at all, but this patch seems to solve the
issue.
When HAVE_FAST_FMAF is set, use the vfma.f32 instruction, when
HAVE_FAST_FMA is set, use the vfma.f64 instruction.
Usually the compiler built-ins will already have inlined these
instructions, but provide these symbols for cases where that doesn't
work instead of falling back to the (inaccurate) common code versions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Anything with fast FMA is assumed to have fast FMAF, along with
32-bit arms that advertise 32-bit FP support and __ARM_FEATURE_FMA
Signed-off-by: Keith Packard <keithp@keithp.com>
32-bit ARM processors with HW float (but not HW double) may define
__ARM_FEATURE_FMA, but that only means they have fast FMA for 32-bit
floats.
Signed-off-by: Keith Packard <keithp@keithp.com>
It was calling __math_uflow(0) instead of __math_uflowf(0), which
resulted in no exception being set on machines with exception support
for float but not double.
Signed-off-by: Keith Packard <keithp@keithp.com>
The main memory region of the GDB simulator ends at address 0xFFBF,
but the simulator linker scripts do not make full use of this available
memory.
>From 61f3d212741acee583e21ff2c2808775584ecad6 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date: Mon, 3 Aug 2020 19:38:23 +0100
Subject: [PATCH 2/2] MSP430: Increase the amount of main memory available in
sim ld scripts
The main memory region of the GDB simulator ends at address 0xFFBF,
but the simulator linker scripts do not make full use of this available
memory.
__{preinit,init,fini}_array_start symbols must be word aligned in
linker scripts. If the section preceding the __*_array_start symbol
has an odd size, then a NULL byte will be present between the start
symbol and the .*_array section itself, when the section gets
automatically word-aligned.
This results in a branch to an invalid address when the CRT startup
code tries to run through the functions listed in the array sections.
>From de115144d05ecbaa82c9c737cc261715ca4b7d67 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date: Mon, 3 Aug 2020 19:09:46 +0100
Subject: [PATCH 1/2] MSP430: Word align __*_array_start symbols in sim linker
scripts
__{preinit,init,fini}_array_start symbols must be word aligned in
linker scripts. If the section preceding the __*_array_start symbol
has an odd size, then a NULL byte will be present between the start
symbol and the .*_array section itself, when the section gets
automatically word-aligned.
This results in a branch to an invalid address when the CRT startup
code tries to run through the functions listed in the array sections.
- update path to Unicode windowsZones.xml file
- drop Windows XP considerations
- regenerate tzmap.h
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This removes the run-time configuration of errno support present in
portions of the math library and unifies all of the compile-time errno
configuration under a single parameter so that the whole library
is consistent.
The run-time support provided by _LIB_VERSION is no longer present in
the public API, although it is still used internally to disable errno
setting in some functions. Now that it is a constant, the compiler should
remove that code when errno is not supported.
This removes s_lib_ver.c as _LIB_VERSION is no longer variable.
Signed-off-by: Keith Packard <keithp@keithp.com>
The __ieee754 functions already return the right value in exception
cases, so don't modify those. Setting the library to _POSIX_/_IEEE_
mode now only affects whether errno is modified.
Signed-off-by: Keith Packard <keithp@keithp.com>
The y0, y1 and yn functions need separate conditions when x is zero as
that returns ERANGE instead of EDOM.
Also stop adjusting the return value from the __ieee754_y* functions
as that is already correct and we were just breaking it.
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch has been inspired by the Linux kernel patch
294f69e662d1 compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use
written by Joe Perches <joe AT perches DOT com> based on an idea from
Dan Carpenter <dan DOT carpenter AT oracle DOT com>. The following text
is from the original log message:
Reserve the pseudo keyword 'fallthrough' for the ability to convert the
various case block /* fallthrough */ style comments to appear to be an
actual reserved word with the same gcc case block missing fallthrough
warning capability.
All switch/case blocks now should end in one of:
break;
fallthrough;
goto <label>;
return [expression];
continue;
In C mode, GCC supports the __fallthrough__ attribute since 7.1,
the same time the warning and the comment parsing were introduced.
Cygwin-only: add an explicit -Wimplicit-fallthrough=5 to the build
flags.
math_errhandling is specified to contain two bits of information:
1. MATH_ERRNO -- Set when the library sets errno
2. MATH_ERREXCEPT -- Set when math operations report exceptions
MATH_ERRNO should match whether the original math code is compiled in
_IEEE_LIBM mode and the new math code has WANT_ERRNO == 1.
MATH_ERREXCEPT should match whether the underlying hardware has
exception support. This patch adds configurations of this value for
RISC-V, ARM, Aarch64, x86 and x86_64 when using HW float.
Signed-off-by: Keith Packard <keithp@keithp.com>
_IEEE_LIBM is the configuration value which controls whether the
original libm functions modify errno. Use that in the new math code as
well so that the resulting library is internally consistent.
Signed-off-by: Keith Packard <keithp@keithp.com>
Currently raw_read makes two passes through the list of clients. On
the first pass it tries to read from the client from which it last
read successfully. On the second pass it tries to read from all
connected clients.
Add a new pass in between these two, in which raw_read tries to read
from all clients that are in the fc_input_avail case. This should be
more efficient in case select was previously called and detected input
available.
Slightly tweak the first pass. If a client is marked as having the
last successful read but reading from it now finds no input, don't
unmark it unless we successfully read from a different client on one
of the later passes.
The fifo_reader thread function and the function select.cc:peek_fifo()
can both change the state of a fifo_client_handler. These changes are
made under fifo_client_lock, so there is no race, but the changes can
still be incompatible.
Add code to make sure that only one of these functions can change the
state from its initial fc_listening state. Whichever function does
this calls the fhandler_fifo::record_connection method, which is now
public so that peek_fifo can call it.
Slightly modify that method to make it suitable for being called by
peek_fifo.
Make a few other small changes to the fifo_reader thread function to
change how it deals with the STATUS_PIPE_CLOSING value that can
(rarely) be returned by NtFsControlFile.
Add commentary to fhandler_fifo.cc to explain fifo_client connect
states and where they can be changed.
Don't try to read from fifo_client_handlers that are in the fc_closing
state. Experiments have shown that this always yields
STATUS_PIPE_BROKEN, so it just wastes a Windows system call.
Re-order the values in enum fifo_client_connect_state to reflect the
new status of fc_closing.
Rename the existing set_state() to query_and_set_state() to reflect
what it really does. (It queries the O/S for the pipe state.) Add a
new set_state() method, which is a standard setter, and a
corresponding getter get_state().
fhandler_fifo::take_ownership() is called from select.cc::peek_fifo
and fhandler_fifo::raw_read and could potentially block indefinitely
if something goes wrong. This is always undesirable in peek_fifo, and
it is undesirable in a nonblocking read. Fix this by adding a timeout
parameter to take_ownership.
Arbitrarily use a 1 ms timeout in peek_fifo and a 10 ms timeout in
raw_read. These numbers may have to be tweaked based on experience.
Replace the call to cygwait in take_ownership by a call to WFSO.
There's no need to allow interruption now that we have a timeout.
fhandler_fifo::take_ownership() tacitly assumes that the current
owner's fifo_reader_thread will be woken up from WFMO when
update_needed_evt is signaled. But it's possible that the the current
owner's fifo_reader_thread is at the beginning of its main loop rather
than in its WFMO call when that event is signaled.
In this case the owner will never see that the event has been
signaled, and it will never update the shared fifo_client_handlers.
The reader that wants to take ownership will then spin its wheels
forever.
Fix this by having the current owner call update_shared_handlers at
the beginning of its loop, if necessary.
microcode is unsigned long long, printed by _small_sprintf using %x;
Cygwin32 used last 4 bytes of microcode for next field MHz, printing 0;
use correct _small_sprintf format %X to print microcode, producing
correct MHz value under Cygwin32
CPUID 7:0 EDX[14] serialize added in linux-next 5.8 by Ricardo Neri-Calderon:
The Intel architecture defines a set of Serializing Instructions (a
detailed definition can be found in Vol.3 Section 8.3 of the Intel "main"
manual, SDM). However, these instructions do more than what is required,
have side effects and/or may be rather invasive. Furthermore, some of
these instructions are only available in kernel mode or may cause VMExits.
Thus, software using these instructions only to serialize execution (as
defined in the manual) must handle the undesired side effects.
As indicated in the name, SERIALIZE is a new Intel architecture
Serializing Instruction. Crucially, it does not have any of the mentioned
side effects. Also, it does not cause VMExit and can be used in user mode.
This new instruction is currently documented in the latest "extensions"
manual (ISE). It will appear in the "main" manual in the future.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/x86/include/asm/cpufeatures.h?id=85b23fbc7d88f8c6e3951721802d7845bc39663d
C compilers may fold const values at compile time, so expressions
which try to elicit underflow/overflow by performing simple
arithemetic on suitable values will not generate the required
exceptions.
Work around this by replacing code which does these arithmetic
operations with calls to the existing __math_xflow functions that are
designed to do this correctly.
Signed-off-by: Keith Packard <keithp@keithp.com>
----
v2:
libm/math: Pass sign to __math_xflow instead of muliplying result
Compiling
#include <sys/select.h>
void f(int X)
{
fd_set set;
FD_ZERO(&set);
FD_SET(X,&set);
FD_CLR(X+1,&set);
(void)FD_ISSET(X+2,&set);
}
results in plenty of gcc warnings when compiled with
-Wconversion -Wsign-conversion:
fds.c:7:2: warning: conversion to ‘long unsigned int’ from ‘int’ may
FD_SET(X,&set);
^~~~~~
[...]
The unsigned NFDBITS macro combined with the signed 1L constant
are causing lots of implicit signed/unsigned type conversions.
Fix this by updating the FD_* macro code to the latest from FreeBSD
and adding an (int) cast to _NFDBITS.
As a side-effect, this fixes the visibility of NFDBITS and
fds_bits (only if __BSD_VISIBLE).
This also eliminates the old, outdated fd_set workaround.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Newlib's posix_spawn has been taken from FreeBSD. The code relies on
BSD-specific behaviour of vfork, namely the fact that vfork blocks
the parent until the child exits or calls execve as well as the fact
that the child shares parent memory in non-COW mode.
This behaviour can't be emulated by Cygwin. Cygwin's vfork is
equivalent to fork. This is POSIX-compliant, but it's lacking BSD's
vfork ingrained synchronization of the parent to wait for the child
calling execve, or the chance to just write a variable and the parent
will see the result.
So this requires a Cygwin-specific solution. The core function of
posix_spawn, called do_posix_spawn is now implemented twice, once using
the BSD method, and once for Cygwin using Windows synchronization under
the hood waiting for the child to call execve and signalling errors
upstream. The Windows specifics are hidden inside Cygwin, so newlib
only calls internal Cygwin functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Stop after we've written the dump in response to the initial breakpoint
EXCEPTION_DEBUG_EVENT we recieve for attaching to the process.
(rather than bogusly sitting there for 20 seconds waiting for more debug
events from a stopped process after we've already written the dump).
ld: libm.a(lib_a-fesetenv.o): in function `fesetenv':
newlib/libm/machine/arm/fesetenv.c:38: undefined reference to `vmsr_fpscr'
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Use the already existing stub files if possible. These files are
necessary to override the stub implementation with the machine-specific
implementation through the build system.
Reviewed-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
The previous fenv support for ARM used the soft-float implementation of
FreeBSD. Newlib uses the one from libgcc by default. They are not
compatible. Having an GCC incompatible soft-float fenv support in
Newlib makes no sense. A long-term solution could be to provide a
libgcc compatible soft-float support. This likely requires changes in
the GCC configuration. For now, provide a stub implementation for
soft-float multilibs similar to RISC-V.
Move implementation to one file and delete now unused files. Hide
implementation details. Remove function parameter names from header
file to avoid name conflicts.
Provide VFP support if __SOFTFP__ is not defined like glibc.
Reviewed-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Signed-off-by: Eshan dhawan <eshandhawan51@gmail.com>
This patch fixes a bug in RISC-V's memcpy implementation where an
integer wraparound occurs when src + size < 8 * sizeof(long), causing
the word-sized copy loop to be incorrectly entered.
Signed-off-by: Chih-Mao Chen <cmchen@andestech.com>
It's working on 32 bit OSes only anyway. It even fails on WOW64.
Drop unsupported NtMapViewOfSection flags.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Use the (undocumented) MEMORY_WORKING_SET_EX_INFORMATION in dumper to
determine if a MEM_IMAGE region is unsharable, and hence has been
modified.
After this, we will end up dumping memory regions where:
- state is MEM_COMMIT (i.e. is not MEM_RESERVE or MEM_FREE), and
-- type is MEM_PRIVATE and protection allows reads (i.e. not a guardpage), or
-- type is MEM_IMAGE and attribute is non-sharable (i.e. it was WC, got
written to, and is now a RW copy)
After this, we will end up dumping memory regions where:
- state is MEM_COMMIT (i.e. is not MEM_RESERVE or MEM_FREE), and
-- type is MEM_PRIVATE and protection allows reads (i.e. not a guardpage), or
-- type is MEM_IMAGE and protection allows writes
Making this decision based on the current protection isn't 100% correct,
because it may have been changed using VirtualProtect(). But we don't
know how to determine if a region is shareable.
(As a practical matter, anything which gets us the stack (MEM_PRIVATE)
and .data/.bss (RW MEM_IMAGE) is going to be enough for 99% of cases)
Keith Packard via Newlib
Takashi Yano
Ken Brown
Jon Turney
Jozef Lawrynowicz
Corinna Vinschen
Brian Inglis
Keith Packard
Sebastian Huber
Eshan dhawan