Since Windows Vista, locale handling is converted from using numeric
locale identifiers (LCID) to using ISO5646 locale strings. In the
meantime Windows introduced new locales which don't even have a LCID
attached. Those were unusable in Cygwin because locale information
for these locales required to call the new locale functions taking
a locale string.
Convert Cygwin to drop LCIDs and use Windows ISO5646 locales instead.
The last place using LCIDs is the __set_charset_from_locale function.
Checking numerically is easier and uslay faster than checking strings.
However, this function is clearly a TODO
Used on Linux as default codeset for Tajik. There's no matching
Windows codepage, so fake it as CP103.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Set __OBSOLETE_MATH_DEFAULT to 0 if 'd' extension is supported (i.e.
__riscv_flen == 64).
Base on the comment for __OBSOLETE_MATH_DEFAULT:
> ... it assumes that the toolchain has ISO C99 support (hexfloat
> literals, standard fenv semantics), the target has IEEE-754 conforming
> binary32 float and binary64 double (not mixed endian) representation,
> standard SNaN representation, double and single precision arithmetics
> has similar latency and it has no legacy SVID matherr support, only
> POSIX errno and fenv exception based error handling.
Signed-off-by: Hau Hsu <hau.hsu@sifive.com>
This patch is for the sake of gnulib.
gnulib implements some form of a thread-safe setlocale variant
called setlocale_null_r, which is supposed to return the locale
strings in a thread-safe manner. This only succeeds if the system's
setlocale already handles this thread-safe, otherwise gnulib adds
some locking on its own.
Newlib's setlocale always writes the global string array holding the
LC_ALL value anew on each invocation of setlocale(LC_ALL, NULL).
Since that doesn't allow to call setlocale(LC_ALL, NULL) in a
thread-safe manner, so locking in gnulib is required.
And here's the problem...
The lock is decorated as dllexport when building for Cygwin. This
collides with the default behaviour of ld to export all symbols.
If it finds one decorated symbol, it will only export this symbol
to the DLL import lib.
Change setlocale so that it writes the global string array
holding the LC_ALL value at the time the locale gets changed.
On setlocale(LC_ALL, NULL), just return the pointer to the
global LC_ALL string array, just as in GLibc. The burden of
doing so is negligibly for all targets, but adds thread-safety
for gnulib's setlocal_null_r() function, and gnulib can drop
the lock entirely when building for Cygwin.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When compiling Newlib for arm targets with GCC 12.1 onward, the
passing of architecture extension information to the assembler is
automatic, making the use of .fpu and .arch_extension directives
in assembly files redundant.
With older versions of GCC, however, these directives must be
hard-coded into the `arm/setjmp.S' file to allow the assembly of
instructions concerning the storage and subsequent reloading of the
floating point registers to/from the jump buffer, respectively.
This patch conditionally adds the `.fpu vfpxd' and `.arch_extension
mve' directives based on compile-time preprocessor macros concerning
GCC version and target architectural features, such that both the
assembly and linking of setjmp.S succeeds for older versions of
Newlib.
We don't have floating-point exception or non-default rounding mode
support for the RISC-V soft-float environment, `feraiseexcept' and
`fesetround' do nothing unless the `__riscv_flen' macro has been set.
Therefore following ISO C language requirements[1] only define macros
for soft float that correspond to actually supported floating-point
environment features, removing failures from GCC testing such as:
FAIL: gcc.dg/torture/fp-int-convert-timode-3.c -O0 execution test
FAIL: gcc.dg/torture/fp-int-convert-timode-4.c -O0 execution test
References:
[1] "Programming languages -- C", ISO/IEC 9899:2023, working draft --
September 3, 2022, Section 7.6 "Floating-point environment <fenv.h>"
Fixes: 7040b2de08 ("Add RISC-V port for libm")
Signed-off-by: Maciej W. Rozycki <macro@embecosm.com>
This is still not properly resolving <https://gcc.gnu.org/PR85463>
'[nvptx] "exit" in offloaded region doesn't terminate process', but is
one step into that direction, and allows for simplifying some GCC code.
... as implemented for GCN in 'newlib/libc/sys/amdgcn/*' files, but (for now)
still adding to the catch-all 'newlib/libc/machine/nvptx/misc.c' file.
This is necessary for the GCC/Fortran I/O system, for example.
Co-authored-by: Andrew Stubbs <ams@codesourcery.com>
Given that nvptx newlib currently restricts itself to ELIX level 1, this
is not already a problem. However, in the following we'd like to lift
that restriction, and then run into:
[...]/newlib/libc/ssp/stack_protector.c: In function ‘__stack_chk_init’:
[...]/newlib/libc/ssp/stack_protector.c:31:1: sorry, unimplemented: global constructors not supported on this target
31 | }
| ^
GCC patch "nvptx: Support global constructors/destructors via 'collect2'"
has been posted, but not yet accepted. Until that is resolved, use the
same manual SSP setup as for GCN.
The libgloss port has been reaching back into newlib internals for a
single header whose contents have been frozen for almost a decade.
To break this backwards libgloss->newlib dependency, move the acle
header to the srcroot include/ so everyone can use the same copy.
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags. Save the PAC value in the jump buffer so that
longjmp can only return to the authenticated location.
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags.
This patch enables PACBTI for all relevant variants of strlen:
* Newlib for armv8.1-m.main+pacbti
* Newlib for armv8.1-m.main+pacbti+mve
* Newlib-nano
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags.
This patch enables PACBTI for all relevant variants of strcmp:
* Newlib for armv8.1-m.main+pacbti
* Newlib for armv8.1-m.main+pacbti+mve
* Newlib-nano
Augment the arm_asm.h header file to simplify function prologues and
epilogues whilst adding support for PACBTI enablement via macros for
hand-written assembly functions. For PACBTI, both prologues/epilogues
as well as cfi-related directives are automatically amended
accordingly, depending on the compile-time mbranch-protection argument
values.
It defines the following preprocessor macros:
* HAVE_PAC_LEAF: Indicates whether pac-signing has been requested for
leaf functions.
* PAC_LEAF_PUSH_IP: Whether leaf functions should push the pac code
to the stack irrespective of whether the ip register is clobbered in
the function or not.
* STACK_ALIGN_ENFORCE: Whether a dummy register should be added to
the push list as necessary in the prologue to ensure stack
alignment preservation at the start of assembly function. The
epilogue behavior is likewise affected by this flag, ensuring any
pushed dummy registers also get popped on function return.
It also defines the following assembler macros:
* prologue: In addition to pushing any callee-saved registers onto
the stack, it generates any requested pacbti instructions.
Pushed registers are specified via the optional `first', `last',
`push_ip' and `push_lr' macro argument parameters.
when a single register number is provided, it pushes that
register. When two register numbers are provided, they specify a
rage to save. If push_ip and/or push_lr are non-zero, the
respective registers are also saved. Stack alignment is requested
via the `align` argument, which defaults to the value of
STACK_ALIGN_ENFORCE, unless manually overridden.
For example:
prologue push_ip=1 -> push {ip}
prologue push_ip=1, align8=1 -> push {r2, ip}
prologue push_ip=1, push_lr=1 -> push {ip, lr}
prologue 1 -> push {r1}
prologue 1, align8=1 -> push {r0, r1}
prologue 1 push_ip=1 -> push {r1, ip}
prologue 1 4 -> push {r1-r4}
prologue 1 4 push_ip=1 -> push {r1-r4, ip}
* epilogue: pops registers off the stack and emits pac key signing
instruction, if requested. The `first', `last', `push_ip',
`push_lr' and `align' function as per the prologue macro,
generating pop instead of push instructions.
Stack alignment is enforced via the following helper macro
call-chain:
{prologue|epilogue} ->_align8 -> _preprocess_reglist ->
_preprocess_reglist1 -> {_prologue|_epilogue}
Finally, the necessary cfi directives for adding debug information
to prologue and epilogue are generated via the following macros:
* cfisavelist - prologue macro helper function, generating
necessary .cfi_offset directives associated with push instruction.
Therefore, the net effect of calling `prologue 1 2 push_ip=1' is
to generate the following:
push {r1-r2, ip}
.cfi_adjust_cfa_offset 12
.cfi_offset 143, -4
.cfi_offset 2, -8
.cfi_offset 1, -12
* cfirestorelist - epilogue macro helper function, emitting
.cfi_restore instructions prior to resetting the cfa offset. As
such, calling `epilogue 1 2 push_ip=1' will produce:
pop {r1-r2, ip}
.cfi_register 143, 12
.cfi_restore 2
.cfi_restore 1
.cfi_def_cfa_offset 0
... 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.
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.
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
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.
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>
This patch fixes warnings that appears when compiling:
#define fwopen(__cookie,__fn) funopen(__cookie, (int (*)())0, __fn,
(fpos_t (*)())0, (int (*)())0)
Expands to:
funopen(__null, (int (*)())0, &app_printf, (fpos_t (*)())0, (int
(*)())0)
argument of type "int (*)()" is incompatible with parameter of type
"int (*)(void *__cookie, char *__buf, int __n)"C/C++(167)
invalid conversion from 'fpos_t (*)()' {aka 'long int (*)()'} to
'fpos_t (*)(void*, fpos_t, int)' {aka 'long int (*)(void*,
Discussion is here:
https://github.com/espressif/arduino-esp32/issues/7407
https://cygwin.com/pipermail/cygwin/2022-December/252571.html
Cygwin's default locale is "C.UTF-8" as far as LC_CTYPE settings
are concerned. However, while __global_locale contains fixed
mbtowc and wctomb pointers, the lc_ctype_T pointer is still pointing
to _C_ctype_locale, representing the standard "C" locale.
The problem with this is that the codeset name as well as MB_CUR_MAX
is wrong.
Fix this by introducing a new lc_ctype_T structure called
_C_utf8_ctype_locale, setting the default codeset to "UTF-8" and
MB_CUR_MAX to 6. Use this as lc_ctype_T pointer in __global_locale
by default on Cygwin.
Fixes: a6a477fa81 ("POSIX-1.2008 per-thread locales, groundwork part 1")
Co-Authored-By: Takashi Yano <takashi.yano@nifty.ne.jp>
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.
..., 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>
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.
- add support for using sysconf to get page size in _mallocr.c via
HAVE_SYSCONF_PAGESIZE flag set in configure.host
- set flag in configure.host for arm and add a default sysconf implementation
in libc/sys/arm that returns the page size
- the default implementation can be overridden outside newlib to allow a
different page size to improve malloc on devices with a small footprint
without needing to rebuild newlib
- this patch is based on a contribution from Torbjorn Svensson and
Niklas Dahlquist (https://ecos.sourceware.org/ml/newlib/current/017616.html)
Previously, the chacha20 instance would be rekeyed every 1.6MB. This
makes it happen at a random point somewhere in the 1-2MB range.
Feedback deraadt@ visa@, ok tb@ visa@
newlib port: Make REKEY_BASE depend on SIZE_MAX
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
In the incredibly unbelievable circumstance where _rs_init() fails to
allocate pages, don't call abort() because of corefile data leakage
concerns, but simply _exit(). The reasoning is _rs_init() will only fail
if someone finds a way to apply specific pressure against this failure
point, for the purpose of leaking information into a core which they can
read. We don't need a corefile in this instance to debug that. So take
this "lever" away from whoever in the future wants to do that.
In the nano version of malloc, when the last chunk is to be extended,
there is no need to acount for the header again as it's already taken
into account in the overall "alloc_size" at the beginning of the
function.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
When using nano malloc and the remaning heap space is not big enough to
fullfill the allocation, malloc will attempt to merge the last chunk in
the free list with a new allocation in order to create a bigger chunk.
This is successful, but the chunk still remains in the free_list, so
any later call to malloc can give out the same region without it first
being freed.
Possible sequence to verify:
void *p1 = malloc(3000);
void *p2 = malloc(4000);
void *p3 = malloc(5000);
void *p4 = malloc(6000);
void *p5 = malloc(7000);
free(p2);
free(p4);
void *p6 = malloc(35000);
free(p6);
void *p7 = malloc(42000);
void *p8 = malloc(32000);
Without the change, p7 and p8 points to the same address.
Requirement, after malloc(35000), there is less than 42000 bytes
available on the heap.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Corinna Vinschen
Hau Hsu
Brian Inglis
Victor L. Do Nascimento
Maciej W. Rozycki
Thomas Schwinge
Mike Frysinger
CompilerAI Research Group
Giovanni Bajo
Alexey Lapshin
Tobias Burnus
Sebastian Huber
Brian Inglis
Markus B. Moessner
Jeff Johnston
tb
djm
dtucker
deraadt
bcook
Torbjörn SVENSSON