Teach makedocbook how to handle some new things seen in the makedoc markup
since bd547490:
- struct lines appearing in the synopsis
- use of @strong{} texinfo markup
The changes in af272aca59 only works when
using gcc/g++ with -E or -save-temps, otherwise newlib's newlib.h gets
used even if -specs=nano.specs is specified. This is because the driver
only use cpp_options spec for the external cpp tool, not for the
integrated one.
This patch uses instead cpp_unique_options which is used in all cases:
it is used directly when the integrated preprocessor is used, and
indirectly by expansion of cpp_options otherwise.
At the moment when targeting bare-metal targets or systems without
definition for the locking primitives newlib, uses dummy empty macros.
This has the advantage of reduced size and faster implementation but
does not allow the application to retarget the locking routines.
Retargeting is useful for a single toolchain to support multiple systems
since then it's only at link time that you know which system you are
targeting.
This patch adds a new configure option
--enable-newlib-retargetable-locking to use dummy empty functions
instead of dummy empty macros. The default is to keep the current
behavior to not have any size or speed impact on targets not interested
in this feature. To allow for any size of lock, the _LOCK_T type is
changed into pointer to struct _lock and the _init function are tasked
with allocating the locks. The platform being targeted must provide the
static locks. A dummy implementation of the locking routines and static
lock is provided for single-threaded applications to link successfully
out of the box.
To ensure that the behavior is consistent (either no locking whatsoever
or working locking), the dummy implementation is strongly defined such
that a partial retargeting will cause a doubly defined link error.
Indeed, the linker will only pull in the file providing the dummy
implementation if it cannot find an implementation for one of the
routine or lock.
Newlib build system defines __SINGLE_THREAD__ to allow concurrency code
to be only compiled when newlib is configured for multithread. One such
example are locks which become useless in single thread mode. Although
most static locks are indeed guarded by !defined(__SINGLE_THREAD__),
some are not.
This commit adds these missing guards to __dd_hash_mutex,
__atexit_recursive_mutex, __at_quick_exit_mutex and __arc4random_mutex.
It also makes sure locking macros in lock.h are noop in single thread
mode.
Hi,
The changes in c028685518 to use
newlib-nano's include directory work for cc1 but not cc1plus. cc1plus
comes with its own cpp spec which does not have a name attached to it.
This patch uses the renaming trick on cpp_options instead of cpp, as
cpp_options is used both by cc1 and cc1plus.
Environ is defined in libgloss and libc:
- libgloss/or1k/syscalls.c
- libc/stdlib/environ.c
When linking we sometimes get errors:
or1k-elf-g++ test.o -mnewlib -mboard=or1ksim -lm -o test
/opt/shorne/software/or1k/lib/gcc/or1k-elf/5.3.0/../../../../or1k-elf/lib/libor1k.a(syscalls.o):(.data+0x0):
multiple definition of `environ'
/opt/shorne/software/or1k/lib/gcc/or1k-elf/5.3.0/../../../../or1k-elf/lib/libc.a(lib_a-environ.o):(.data+0x0):
first defined here
collect2: error: ld returned 1 exit status
This doesnt happen after the fix. Basic things build fine too.
There was an issue revealed in gdb testing where C++ virtual tables
were not getting properly initialized. This seems to be due to the
c++ global constructors moving from ctors to init_array.
This fix makes sure we call the proper method for initializing the
constructors in all places.
or1k uses reentrant calls by default, but there was no open_r defined
which caused failure in C++/C code such as:
int main() { std::cout << "test\n"; return 0; }
or
int main() {open(".", 0);}
Match glibc behaviour to expose the public bswap_* macros only with an
explicity #include <byteswap.h>; #include'ing <endian.h> should not expose
them.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
In preparation for the patch that would allow retargeting of locking
routines, rename all lock objects to follow this pattern:
"__<name>_[recursive_]mutex".
Following locks were renamed:
__dd_hash_lock -> __dd_hash_mutex
__sfp_lock -> __sfp_recursive_mutex
__sinit_lock -> __sinit_recursive_mutex
__atexit_lock -> __atexit_recursive_mutex
_arc4random_mutex -> __arc4random_mutex
__env_lock_object -> __env_recursive_mutex
__malloc_lock_object -> __malloc_recursive_mutex
__atexit_mutex -> __at_quick_exit_mutex
__tz_lock_object -> __tz_mutex
Give more elements ids, so random ids aren't assigned to them, so anchors
are stable between builds.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Don't set SO_RCVBUF/SO_SNDBUF to fixed values, thus disabling autotuning.
Patch modeled after a patch suggestion from Daniel Havey <dhavey@gmail.com>
in https://cygwin.com/ml/cygwin-patches/2017-q1/msg00010.html:
At Windows we love what you are doing with Cygwin. However, we have
been getting reports from our hardware vendors that iperf is slow on
Windows. Iperf is of course compiled against the cygwin1.dll and we
believe we have traced the problem down to the function fdsock in
net.cc. SO_RCVBUF and SO_SNDBUF are being manually set. The comments
indicate that the idea was to increase the buffer size, but, this code
must have been written long ago because Windows has used autotuning
for a very long time now. Please do not manually set SO_RCVBUF or
SO_SNDBUF as this will limit your internet speed.
I am providing a patch, an STC and my cygcheck -svr output. Hope we
can fix this. Please let me know if I can help further.
Simple Test Case:
I have a script that pings 4 times and then iperfs for 10 seconds to
debit.k-net.fr
With patch
$ bash buffer_test.sh 178.250.209.22
usage: bash buffer_test.sh <iperf server name>
Pinging 178.250.209.22 with 32 bytes of data:
Reply from 178.250.209.22: bytes=32 time=167ms TTL=34
Reply from 178.250.209.22: bytes=32 time=173ms TTL=34
Reply from 178.250.209.22: bytes=32 time=173ms TTL=34
Reply from 178.250.209.22: bytes=32 time=169ms TTL=34
Ping statistics for 178.250.209.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 167ms, Maximum = 173ms, Average = 170ms
------------------------------------------------------------
Client connecting to 178.250.209.22, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.137.196.108 port 58512 connected with 178.250.209.22 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 768 KBytes 6.29 Mbits/sec
[ 3] 1.0- 2.0 sec 9.25 MBytes 77.6 Mbits/sec
[ 3] 2.0- 3.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 3.0- 4.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 4.0- 5.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 5.0- 6.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 6.0- 7.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 7.0- 8.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 8.0- 9.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 9.0-10.0 sec 18.0 MBytes 151 Mbits/sec
[ 3] 0.0-10.0 sec 154 MBytes 129 Mbits/sec
Without patch:
dahavey@DMH-DESKTOP ~
$ bash buffer_test.sh 178.250.209.22
Pinging 178.250.209.22 with 32 bytes of data:
Reply from 178.250.209.22: bytes=32 time=168ms TTL=34
Reply from 178.250.209.22: bytes=32 time=167ms TTL=34
Reply from 178.250.209.22: bytes=32 time=170ms TTL=34
Reply from 178.250.209.22: bytes=32 time=169ms TTL=34
Ping statistics for 178.250.209.22:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 167ms, Maximum = 170ms, Average = 168ms
------------------------------------------------------------
Client connecting to 178.250.209.22, TCP port 5001
TCP window size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 10.137.196.108 port 58443 connected with 178.250.209.22 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 512 KBytes 4.19 Mbits/sec
[ 3] 1.0- 2.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 2.0- 3.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 3.0- 4.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 4.0- 5.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 5.0- 6.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 6.0- 7.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 7.0- 8.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 8.0- 9.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 9.0-10.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 0.0-10.1 sec 14.1 MBytes 11.7 Mbits/sec
The output shows that the RTT from my machine to the iperf server is
similar in both cases (about 170ms) however with the patch the
throughput averages 129 Mbps while without the patch the throughput
only averages 11.7 Mbps. If we calculate the maximum throughput using
Bandwidth = Queue/RTT we get (212992 * 8)/0.170 = 10.0231 Mbps. This
is just about what iperf is showing us without the patch since the
buffer size is set to 212992 I believe that the buffer size is
limiting the throughput. With the patch we have no buffer limitation
(autotuning) and can develop the full potential bandwidth on the link.
If you want to duplicate the STC you will have to find an iperf server
(I found an extreme case) that has a large enough RTT distance from
you and try a few times. I get varying results depending on Internet
traffic but without the patch never exceed the limit caused by the
buffering.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The form data sent to the server should be application/x-www-form-urlencoded
This replaces spaces with '+' before being RFC 1738 encoded, so a literal
'+' must be %-encoded also.
See https://cygwin.com/ml/cygwin/2014-01/msg00287.html et seq.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
The termios code doesn't handle erasing of multibyte characters
in canonical mode, it always erases a single byte. When entering
a multibyte character and then pressing VERASE, the input ends up
with an invalid character.
Following Linux we introduce the IUTF8 input flag now, set by
default. When this flag is set, VERASE or VWERASE will check
if the just erased input byte is a UTF-8 continuation byte. If
so, it erases another byte and checks again until the entire
UTF-8 character has been removed from the input buffer.
Note that this (just as on Linux) does NOT work with arbitrary
multibyte codesets. This only works with UTF-8.
For a discussion what happens, see
https://cygwin.com/ml/cygwin/2017-01/msg00299.html
Sidenote: The eat_readahead function is now member of fhandler_termios,
not fhandler_base. That's necessary to get access to the terminal's
termios flags.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
After a binutils change "a while ago" (2015-12) to default to
--enable-initfini-array, i.e. to merge .ctors and .dtors into
.init_array and .fini_array, this is needed for cdtors to run at all.
Based on what goes on in arm/ and aarch64/. Tested for cris-elf by
running the gcc testsuite.
By the way, the configure test doesn't detect this change, so the
HAVE_INITFINI_ARRAY ifdeffery is somewhat redundant. Still, the
change is tested to be safe with older binutils too.
libgloss/
* cris/crt0.S, cris/lcrt0.c: Include newlib.h.
[HAVE_INITFINI_ARRAY] (_init): Define to __libc_init_array.
[HAVE_INITFINI_ARRAY] (_fini): Ditto __libc_fini_array.
In patch b219285f87 you have a syntax
error in the PLD instruction. The syntax for the pld argument should be
in square brackets as it's a memory address like so: pld [r1]. With
your patch the newlib build fails for armv7-a targets. This patch fixes
the build failures.
Tested by making sure the newlib build completes successfully.
2016-01-26 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
* libc/machine/arm/strcpy.c (strcpy): Fix PLD assembly syntax.
* libc/machine/arm/strlen-stub.c (strlen): Likewise.
LTO can re-order top-level assembly blocks, which can cause this
macro definition to appear after its use (or not at all), causing
compilation failures. On modern toolchains (armv4t+), assembly
should write `bx lr` in all cases, and linkers will transparently
convert them to `mov pc, lr`, allowing us to simply remove the
macro.
(source: https://groups.google.com/forum/#!topic/comp.sys.arm/3l7fVGX-Wug
and verified empirically)
For the armv4.S file, preserve this macro to maximize backwards
compatibility.
LTO can re-order top-level assembly blocks, which can cause this
macro definition to appear after its use (or not at all), causing
compilation failures. As the macro has very few uses, simply removing
it by inlining is a simple fix.
n.b. one of the macro invocations in strlen-stub.c was already
guarded by the relevant #define, so it is simply converted directly
to a pld
Remove stray commas. Include <sys/cdefs.h> for __restrict (includes
<stddef.h> indirectly).
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Hi,
With the patch to allow newlib's locking routine to be retargeted currently
under discussion, we need to start thinking of locks as part of newlib's ABI
since newlib depends on specific names being provided by the OS. This patch
renames 2 locks so that they follow the same naming convention as other locks.
It needs to be applied before the retargeting patch, while locks are still an
internal consideration.
Newlib builds successfully with this change.
Ok for master branch?
Best regards,
Thomas
Provide an extension NL_LOCALE_NAME() macro, with semantics
matching glibc, which can be used as:
nl_langinfo_l(NL_LOCALE_NAME(LC_MESSAGES), locale);
to get back the locale string that locale was originally
created with during newlocale(). This in turn allows a library
(such as gettext) to determine what thread-local locale settings
it has inherited from the main program without having to be told
what parameters were passed to newlocale(), for less overall
coupling between parts of the program.
gnulib is set up to use the extension:
https://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00129.html
* libc/include/langinfo.h (NL_LOCALE_NAME): New macro
* libc/locale/nl_langinfo.c (nl_langinfo_l): Expose locale names
of a locale_t's category components.
Signed-off-by: Eric Blake <eblake@redhat.com>
- Drop virtual_key_code (only used once)
- Convert macros wch and control_key_state to const vars
unicode_char and ctrl_key_state.
- Fix formatting
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Create two new inline functions is_alt_numpad_key(PINPUT_RECORD) and
is_alt_numpad_event(PINPUT_RECORD) which contain the actual checks.
Call these functions from fhandler_console::read and peek_console for
better readability.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
{p}select/{p}poll completely ignored Alt+Numpad key sequences in console
input which results in newer readline using pselect to fail handling such
sequences correctly. See https://cygwin.com/ml/cygwin/2017-01/msg00135.html
During debugging and testing it turned out that while reading console
input, single key presses during an Alt+Numpad sequences where not
ignored, so ultimately a sequence like
Alt-down Numpad-1 Numpad-2 Numpad-3
whihc is supposed to result in a single character in the input stream
will actually result in 4 chars in the input stream, three control
sequences and the actual character.
Both problems should be fixed by this patch.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
A few files were missing headers for memset/malloc, likely missed
because the files don't directly call the functions, rather they
come in via macros in libc/include/sys/reent.h:
#define _REENT_CHECK(var, what, type, size, init) do { \
struct _reent *_r = (var); \
if (_r->what == NULL) { \
_r->what = (type)malloc(size); \
#define _REENT_CHECK_ASCTIME_BUF(var) \
_REENT_CHECK(var, _asctime_buf, char *, _REENT_ASCTIME_SIZE, \
memset((var)->_asctime_buf, 0, _REENT_ASCTIME_SIZE))
Without these fixes, implicit function signatures are provided,
which gcc warns could cause aliasing issues down the line:
../../../../../../../newlib-2.5.0/newlib/libc/time/asctime.c:62:3: warning: type of 'memset' does not match original declaration [-Wlto-type-mismatch]
/Volumes/code/external/newlib-cygwin/newlib/libc/include/string.h:29:7: note: return value type mismatch
_PTR _EXFUN(memset,(_PTR, int, size_t));
^
/Volumes/code/external/newlib-cygwin/newlib/libc/include/string.h:29:7: note: 'memset' was previously declared here
/Volumes/code/external/newlib-cygwin/newlib/libc/include/string.h:29:7: note: code may be misoptimized unless -fno-strict-aliasing is used
../../../../../../../newlib-2.5.0/newlib/libc/time/asctime.c:62:3: warning: type of 'malloc' does not match original declaration [-Wlto-type-mismatch]
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: return value type mismatch
extern _PTR malloc _PARAMS ((size_t));
^
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: 'malloc' was previously declared here
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: code may be misoptimized unless -fno-strict-aliasing is used
../../../../../../../newlib-2.5.0/newlib/libc/time/lcltime.c:58:3: warning: type of 'malloc' does not match original declaration [-Wlto-type-mismatch]
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: return value type mismatch
extern _PTR malloc _PARAMS ((size_t));
^
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: 'malloc' was previously declared here
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: code may be misoptimized unless -fno-strict-aliasing is used
../../../../../../../newlib-2.5.0/newlib/libc/string/strsignal.c:70:3: warning: type of 'malloc' does not match original declaration [-Wlto-type-mismatch]
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: return value type mismatch
extern _PTR malloc _PARAMS ((size_t));
^
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: 'malloc' was previously declared here
/Volumes/code/external/newlib-cygwin/newlib/libc/include/malloc.h:37:13: note: code may be misoptimized unless -fno-strict-aliasing is used
Including the proper headers elminates the implicit function
signatures and these warnings.
This patch fixes the following problem:
Commit 9636c426 refactored the pipe code especially to make sure
to call WriteFile only with chunks matching the maximum atomic write
count. This accidentally introduced a small change in behaviour
on blocking pipes due to the success case falling through into the
error case. Rather then writing atomic chunks until all bytes are
written, the code immediately broke from the loop after writing
the first chunk, basically the same as in case of non-blocking
writes. This behaviour is not compliant to POSIX which requires
"Write requests to a pipe or FIFO [...]
* If the O_NONBLOCK flag is clear, a write request may cause the
thread to block, but on normal completion it shall return nbyte."
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Corinna Vinschen