This fixes a bug introduced in a previous patch (Commit 44b60f0c:
Make __sdidinit unused). Removed intitialization of __cleanup from
__smakebuf_r(). All callers of __smakebuf_r() call __sinit()
through the_CHECK_INIT macro, thus __cleanup is already
initialized. This fix also allows _cleanup_r() to be made static.
Changed its name to cleanup_stdio() and removed its declaration
from local.h.
Rename __sfmoreglue() in sfmoreglue() and make it static. This function is
only used by __sfp() in the same translation unit.
Remove use of register keyword.
[PATCH] newlib: Only call _fputwc_r if ELIX_LEVEL >= 4
(nano-)vfprintf.c is enabled for ELIX_LEVEL >= 1. When _WIDE_ORIENT
is set, its __sprint_r / __sfputs_r functions unconditionally called
_fputwc_r which is only in ELEX_LEVEL >= 4. With this commit,
the _WIDE support in (nano-)vfprintf.c is disabled for ELEX_LEVEL < 4.
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.
Some of these rules were already unnecessary as they were compiling a
single source file into the same named object w/out custom flags, and
Automake handles that for us completely.
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 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.
Remove dependency on __sdidinit member of struct _reent to check
object initialization. Like __sdidinit, the __cleanup member of
struct _reent is initialized in the __sinit() function. Checking
initialization against __cleanup serves the same purpose and will
reduce overhead in the __sfp() function in a follow up patch.
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.
Generating these files is very cheap, so let's just do it all the time.
This makes the build logic simpler, and keeps errors for slipping in in
codepaths that are not well tested. Creating these files doesn't mean
they'll be included in the manual implicitly.
For example, some of the nano stdio files break documentation because
they don't have any chew directives in them. But no one noticed since
that code path is rarely enabled. So drop the _i and _float def files.
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.
The 'cygnus' option was removed from automake 1.13 in 2012, so the
presence of this option prevents that or a later version of automake
being used.
A check-list of the effects of '--cygnus' from the automake 1.12
documentation, and steps taken (where possible) to preserve those
effects (See also this thread [1] for discussion on that):
[1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html
1. The foreign strictness is implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
2. The options no-installinfo, no-dependencies and no-dist are implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
Future work: Remove no-dependencies and any explicit header dependencies,
and use automatic dependency tracking instead. Are there explicit rules
which are now redundant to removing no-installinfo and no-dist?
3. The macro AM_MAINTAINER_MODE is required.
Already present in newlib/acinclude.m4
Note that maintainer-mode is still disabled by default.
4. Info files are always created in the build directory, and not in the
source directory.
This appears to be an error in the automake documentation describing
'--cygnus' [2]. newlib's info files are generated in the source
directory, and no special steps are needed to keep doing that.
[2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html
5. texinfo.tex is not required if a Texinfo source file is specified.
(The assumption is that the file will be supplied, but in a place that
automake cannot find.)
This effect is overriden by an explicit setting of the TEXINFO_TEX
variable (the directory part of which is fed into texi2X via the
TEXINPUTS environment variable).
6. Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
For obscure automake reasons, this effect of '--cygnus' is not active
for makeinfo in newlib's configury.
However, there appears to be top-level configury which selects in-tree
runtest, expect and makeinfo, if present. So, if that works as it
appears, this effect is preserved. If not, this may cause problem if
anyone is building those tools in-tree.
This effect is not preserved for texi2dvi. This may cause problems if
anyone is building texinfo in-tree.
If needed, explicit checks for those tools looking in places relative to
$(top_srcdir)/../ as well as in PATH could be added.
7. The check target doesn't depend on all.
This effect is not preseved. The check target now depends on the all
target.
This concern seems somewhat academic given the current state of the
testsuite.
Also note that this doesn't touch libgloss.
- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
of frexpl() function. With this patch, frexpl() function has been
implemented in libm to solve this issue.
Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
svfwscanf replaces getwc and ungetwc_r. The comments in the code talk
about avoiding file operations, but they also need to bypass the
mbtowc calls as svfwscanf operates on wchar_t, not multibyte data,
which is a more important reason here; they would not work correctly
otherwise.
The ungetwc replacement has code which uses the 3 byte FILE _ubuf
field, but if wchar_t is 32-bits, this field is not large enough to
hold even one wchar_t value. Building in this mode generates warnings
about array overflow:
In file included from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/stdio/vfwscanf.c: In function '_sungetwc_r.isra':
../../newlib/libc/stdio/vfwscanf.c:316:12: warning: array subscript 4294967295 is above array bounds of 'unsigned char[3]' [-Warray-bounds]
316 | fp->_p = &fp->_ubuf[sizeof (fp->_ubuf) - sizeof (wchar_t)];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../newlib/libc/stdio/stdio.h:46,
from ../../newlib/libc/stdio/vfwscanf.c:82,
from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/include/sys/reent.h:216:17: note: while referencing '_ubuf'
216 | unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
| ^~~~~
However, the vfwscanf code *never* ungets data before the start of the
scanning operation, and *always* ungets data which matches the input
at that point, so the code always hits the block which backs up over
the input data and never hits the block which uses the _ubuf field.
In addition, the svfwscanf code will always start with the unget
buffer empty, so the ungetwc replacement never needs to support an
unget buffer at all.
Simplify the code by removing support for everything other than
backing up over the input data, leaving the check to make sure it
doesn't get underflowed in case the vfscanf code has a bug in it.
Signed-off-by: Keith Packard <keithp@keithp.com>
The scanf code was skipping the '0' after the 'x' causing the
resulting buffer to contain an invalid number when passed to strtod.
Signed-off-by: Keith Packard <keithp@keithp.com>
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures. A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.
Introduce a new configure variable called "shared_machine_dir". This
dir can then be used for headers shared between architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The MSP430 target supports both 16-bit and 20-bit size_t and intptr_t.
Some implicit casts in Newlib expect these types to be
"long", (a 32-bit type on MSP430) which causes warnings during
compilation such as:
"cast from pointer to integer of different size"
This edits licenses held by Berkeley and NetBSD, both of which
have removed the advertising requirement from their licenses.
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 59362c80e3.
This breaks gnulib's autoconf test for POSIX compatibility of
fflush/fseek. After fflush/fseek, ftello and lseek are out of
sync, with lseek having the wrong offset. This breaks backward
compatibility with Cygwin applications.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The call to fflush was invalidating the read buffer, preventing relative
seeks to positions that would have been inside the read buffer from
being optimized. The call to srefill would then re-read mostly the same
data that was initially in the read buffer.
newlib's vfwscanf(3) (or specifically, __SVFWSCANF_R()) fails to correctly set
the assignment-suppressing character (`*') flag[1] which, when present in the
formatting string, results in undefined behaviour comprising retrieving and
dereferencing a pointer that was not supplied by the caller as such or at all.
When compared to the vfscanf(3) implementation, this would appear to be over
the missing goto match_failure statement preceded by the flags test seen below.
Hence, this patch (re)introduces it.
[1] <http://pubs.opengroup.org/onlinepubs/009695399/functions/fwscanf.html>
--
Sebastian Huber
Matt Joyce
Jeff Johnston
Mike Frysinger
Jon Turney
Takashi Yano
Keith Packard
Corinna Vinschen
Jozef Lawrynowicz
Bastien Bouclet
Lucio Andrés Illanes Albornoz
Jon Beniston