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>
- 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>
By default, Newlib uses a huge object of type struct _reent to store
thread-specific data. This object is returned by __getreent() if the
__DYNAMIC_REENT__ Newlib configuration option is defined.
The reentrancy structure contains for example errno and the standard input,
output, and error file streams. This means that if an application only uses
errno it has a dependency on the file stream support even if it does not use
it. This is an issue for lower end targets and applications which need to
qualify the software according to safety standards (for example ECSS-E-ST-40C,
ECSS-Q-ST-80C, IEC 61508, ISO 26262, DO-178, DO-330, DO-333).
If the new _REENT_THREAD_LOCAL configuration option is enabled, then struct
_reent is replaced by dedicated thread-local objects for each struct _reent
member. The thread-local objects are defined in translation units which use
the corresponding object.
Add a _REENT_CVTBUF() macro to encapsulate access to the _cvtbuf
member of struct reent. This will help to replace the struct
member with a thread-local storage object in a follow up patch.
Add a _REENT_CVTLEN() macro to encapsulate access to the _cvtlen
member of struct reent. This will help to replace the struct
member with a thread-local storage object in a follow-up patch.
Add a _REENT_ERRNO() macro to encapsulate the access to the
_errno member of struct reent. This will help to replace the
structure member with a thread-local storage object in a follow
up patch.
Replace uses of __errno_r() with _REENT_ERRNO(). Keep __errno_r() macro for
potential users outside of Newlib.
For the exit processing only members of _GLOBAL_REENT were used by default. If
the _REENT_GLOBAL_ATEXIT option was enabled, then the data structures were
provided through dedicated global objects. Make this option the default.
Remove the option. Rename struct _reent members _atexit and _atexit0 to
_reserved_6 and _reserved_7, respectively. Provide them only if
_REENT_BACKWARD_BINARY_COMPAT is defined.
The nano malloc build broke with:
Commit 357d7fcc6
In <stdio.h> provide only necessary types
The above commit exposed a latent missing-header bug:
newlib/libc/stdlib/nano-mallocr.c:220:33: error: ‘uintptr_t’ undeclared (first use in this function)
Fix by including <stdint.h>.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
By including sys/_stdint.h, all types from stdint.h are
exposed even if stdint.h isn't pulled in explicitely. Include
<machine/_default_types.h instead. Fix up newlib and Cygwin
files which rely on stdint.h types, too.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Convert all the libc/ subdir makes into the top-level Makefile. This
allows us to build all of libc from the top Makefile without using any
recursive make calls. This is faster and avoids the funky lib.a logic
where we unpack subdir archives to repack into a single libc.a. The
machine override logic is maintained though by way of Makefile include
ordering, and source file accumulation in libc_a_SOURCES.
There's a few dummy.c files that are no longer necessary since we aren't
doing the lib.a accumulating, so punt them.
The winsup code has been pulling the internal newlib ssp library out,
but that doesn't exist anymore, so change that to pull the objects.
Rather than define per-object rules in the Makefile, have small files
that define & include the right content. This simplifies the build
rules, and makes understanding the source a little easier (imo) as it
makes all the subdirs behave the same: you have 1 source file and it
produces 1 object. It's also about the same amount of boiler plate,
without having to define custom build rules that can fall out of sync.
This will also be important as we merge the libc.a build into the top
dir since it relies on a single flat list of objects for overrides.
Also take the opportunity to clean up the unnecessary header deps in
here. Automake provides dependency generation for free now.
This file is a little confusing: it provides all of the mallocr logic,
but is compiled multiple times to produce a unique symbol each time.
For example, building mallocr.c with -DDEFINE_FREER produces freer.o
that only defines _free_r(). This is fine for most symbols, but it's
a little confusing when defining mallocr itself -- we produce a file
with the same symbol name, but we still need -DDEFINE_MALLOCR. In
order to move the logic from the build rules to source files, using
mallocr.c both as a multiplexer and for defining a single symbol is a
bit tricky. It's possible (if we add a lot of redundant preprocessor
checks to mallocr.c, or we add complicated build flags just for this
one files), but it's easier if we simply rename this to a dedicated
file. So let's do that.
We do this as a dedicated commit because the next one will create a
new mallocr.c file and git's automatic diff algorithms can handle
trivial renames, but it can't handle renames+creates in the same
commit.
Simplify the build system logic a bit by moving the mallocr.c ->
nano-mallocr.c redirection from the Makefile to the source files.
This allows for consistent object name usage regardless of the
configuration options used in case a machine dir wants to define
its own override.
Since we already set up _LIBC to indicate source files are building
for newlib, we don't need this malloc-specific symbol. Convert it
over to simplify the build a bit.
This kills off the last configure script under libc/ and folds it
into the top newlib configure script. The a lot of the logic was
already in the top configure script, so move what's left into a
libc/acinclude.m4 file.
The crt0.o was handled in a subdir-by-subdir basis: it would be compiled
in one (e.g. libc/sys/$arch/), then copied up one level (libc/sys/), then
copied up another (libc/) before finally being copied & installed in the
top newlib dir. The libc/sys/ copy was cleaned up, and then the top dir
was changed to copy it directly out of the libc/sys/$arch/ dir. But the
libc/sys/ copy to libc/ was left behind. Clean that up now too.
This is used in a bunch of places, but nowhere is it ever set, and
nowhere can I find any documentation, nor can I find any other project
using it. So delete the flags to simplify.
This was only ever used for i?86-pc-linux-gnu targets, but that's been
broken for years, and has since been dropped. So clean this up too.
This also deletes the funky objectlist logic since it only existed for
the libtool libraries. Since it was the only thing left in the small
Makefile.shared file, we can punt that too.
Now that we use AC_NO_EXECUTABLES, and we require a recent version of
autoconf, we don't need to define our own copies of these macros. So
switch to the standard AC_PROG_CC.
This allows building the libc & libm pages in parallel, and drops
the duplication in the subdirs with the chew/chapter settings.
The unused rules in Makefile.shared are left in place to minimize
noise in the change.
This doesn't migrate all the docs, just the libc's manual (pdf/info).
This is to show the basic form of migrating the chew files.
For subdirs that didn't have any docs, I've stripped their settings
for clarity. If someone wanted to suddenly add docs, they can add
the corresponding Makefile.inc files easily.
THe stdio subdir is actually required by the documentation. The
stdio/def is handled dynamically, but libc.texi always expects it
to be included, and fails if it isn't. So making it required when
building docs is safe.
The xdr subdir is handled dynamically, but it doesn't include any
docs, so the dynamic logic isn't (currently) adding any value. So
making it required when building docs is safe.
That leaves: iconv, stdio64, posix, and signal subdirs. The chapters
have a little disclaimer saying they are system-dependent, but even
then, imo having stable manuals regardless of the target is preferable,
and we can add more disclaimer language to these chapters if we want.
This doesn't touch the man page codepaths, just the info/pdf.
When using the top-level configure script but subdir Makefiles, the
newlib_basedir value gets a bit out of sync: it's relative to where
configure lives, not where the Makefile lives. Move the abs setting
from the top-level configure script into acinclude.m4 so we can rely
on it being available everywhere. Although this commit doesn't use
it anywhere, just lays the groundwork.
The machine configure scripts are all effectively stub scripts that
pass the higher level options to its own makefile. There were only
three doing custom tests. The rest were all effectively the same as
the libc/ configure script.
So instead of recursively running configure in all of these subdirs,
generate their makefiles from the top-level configure. For the few
unique ones, deploy a pattern of including subdir logic via m4:
m4_include([machine/nds32/acinclude.m4])
Some of the generated machine makefiles have a bunch of extra stuff
added to them, but that's because they were inconsistent in their
configure libtool calls. The top-level has it, so it exports some
new vars to the ones that weren't already.
The sys/{configure,Makefile} files exist to fan out to the specific
sys/$arch/ subdir, and to possibly generate a crt0. We already have
all that same info in the libc/ dir itself, so by moving the recursive
configure and make calls into it, we can cut off some of this logic
entirely and save the overhead.
For arches that don't have a sys subdir, it means they can skip the
logic entirely.
The sys subdir itself is kept for the crt0 logic, for now. We'll try
and clean that up next.
The machine/{configure,Makefile} files exist only to fan out to the
specific machine/$arch/ subdir. We already have all that same info
in the libc/ dir itself, so by moving the recursive configure and
make calls into it, we can cut off this logic entirely and save the
overhead.
For arches that don't have a machine subdir, it means they can skip
the logic entirely. Although there's prob not too many of those.
This was added decades ago, but the commit message lacks any
explanation, and it was unused when it was merged. It's still
unused today. So punt it all.
This define is only used by newlib internally, so stop exporting it
as HAVE_INITFINI_ARRAY since this can conflict with defines packages
use themselves.
We don't really need to add _ to HAVE_INIT_FINI too since it isn't
exported in newlib.h, but might as well be consistent here.
We can't (easily) add this to newlib_cflags like HAVE_INIT_FINI is
because this is based on a compile-time test in the top configure,
not on plain shell code in configure.host. We'd have to replicate
the test in every subdir in order to have it passed down.
This matches what the other GNU toolchain projects have done already.
The generated diff in practice isn't terribly large. This will allow
more use of subdir local.mk includes due to fixes & improvements that
came after the 1.11 release series.
The newlib & libgloss dirs are already generated using autoconf-2.69.
To avoid merging new code and/or accidental regeneration using diff
versions, leverage config/override.m4 to pin to 2.69 exactly. This
matches what gcc/binutils/gdb are already doing.
The README file already says to use autoconf-2.69.
To accomplish this, it's just as simple as adding -I flags to the
top-level config/ dir when running aclocal. This is because the
override.m4 file overrides AC_INIT to first require the specific
autoconf version before calling the real AC_INIT.
Since automake deprecated the INCLUDES name in favor of AM_CPPFLAGS,
change all existing users over. The generated code is the same since
the two variables have been used in the same exact places by design.
There are other cleanups to be done, but lets focus on just renaming
here so we can upgrade to a newer automake version w/out triggering
new warnings.