Commit 8a3b3bb4d7 changed the guard on
some functions from _POSIX_THREADS to __POSIX_VISIBLE. As a consequence,
some use of siginfo_t and pthread_t became visible under configurations
where _POSIX_THREADS is unset but __POSIX_VISIBLE is. Build then fails
because the definition of those types are still unavailable.
This commit make those type definition visible for __POSIX_VISIBLE
configurations. This requires moving the siginfo_t definition out of the
RTEMS specific definitions in sys/signal.h while still guarding it
against cygwin case.
There are two common sigpause variants, both of which take an int argument.
If you request _XOPEN_SOURCE or _GNU_SOURCE, you get the System V version,
which removes the given signal from the process's signal mask; otherwise
you get the BSD version, which sets the process's signal mask to the given
value.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
While POSIX allows these functions to also be defined as macros in C, in
C++ this is not allowed, and prevents these names (particularly feof) from
being used in a custom namespace.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
For whatever reason FreeBSD renames several functions provided by
<arpa/inet.h> and uses weak references to provide the standard function
names. This causes problems on targets lacking proper support for weak
references. We do not need this function renaming on RTEMS.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Don't over-read memory returned by _DTOA_R, and never write to it
since the result might be a string literal.
For example, when doing:
swprintf(tt, 20, L"%.*f", 6, 0.0);
we will get back "0".
Instead, write the result returned by _DTOA_R to the output buffer.
After this, write the 0 chars directly to the the output buffer
(if there are any). This also has the (marginal) advantage that
we read/write less memory overall.
According to the FreeBSD man page BIT_CMP() returns true in case the two
sets are NOT equal.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Add the POSIX header files
* arpa/inet.h
* net/if.h
* netdb.h
* netinet/in.h
* netinet/tcp.h
* sys/socket.h
* sys/syslog.h
* sys/uio.h
* sys/un.h
* syslog.h
* termios.h
and their dependencies for RTEMS. The origin of these files is the
latest FreeBSD.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Make the RTEMS <sys/cpuset.h> compatible with the latest FreeBSD
version.
Fix the CPU_COPY() parameter order, see also:
https://devel.rtems.org/ticket/3023
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Use a dedicated header file <machine/_bitcount.h> to avoid cyclic header
dependencies in future changes.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The implementation of the POSIX access() function is nothing machine
specific like memcpy(), etc. Move it back to the system domain. This
avoids problems due to the include search order of the Newlib/GCC build
which picks up machine includes before system includes.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Increase the MSIZE for RTEMS to be in line with the latest FreeBSD
version. The legacy network stack of RTEMS will provides its own
definition.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Update the RTEMS <machine/param.h> and <sys/param.h> to be compatible
with the latest FreeBSD version.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Split the QUEUE_MACRO_DEBUG into QUEUE_MACRO_DEBUG_TRACE and
QUEUE_MACRO_DEBUG_TRASH.
Add the debug macrso QMD_IS_TRASHED() and QMD_SLIST_CHECK_PREVPTR().
Document these in queue.3.
Reviewed by: emaste
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D3984
Add two new macros, SLIST_CONCAT and LIST_CONCAT. Note in both the
queue.h header file and in the queue.3 manual page that they are O(n) so
should be used only in low-usage paths with short lists (otherwise an
STAILQ or TAILQ should be used).
Reviewed by: kib
Make the system queue header file fully usable within C++ programs by
adding macros to define class lists.
This change is backwards compatible for all use within C and C++
programs. Only C++ programs will have added support to use the queue
macros within classes. Previously the queue macros could only be used
within structures.
The queue.3 manual page has been updated to describe the new
functionality and some alphabetic sorting has been done while
at it.
Differential Revision: https://reviews.freebsd.org/D2745
PR: 200827 (exp-run)
MFC after: 2 weeks
Add new FOREACH_FROM variants of the queue(3) FOREACH macros which can
optionally start the traversal from a previously found element by
passing the element in as "var". Passing a NULL "var" retains the same
semantics as the regular FOREACH macros.
Kudos to phk for suggesting the "FROM" suffix instead of my original
proposal.
Reviewed by: jhb (previous version), rpaulo
MFC after: 1 week
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
For example, the FreeBSD GCC (4.2.1) has a spotty support for that
feature. If the static keyword is used with an unnamed array parameter
in a function declaration, then the compilation fails with:
error: static or type qualifiers in abstract declarator
The feature does work if the parameter is named.
So, the restriction introduced in this commit can be removed when all
affected function prototypes have the workaround.
MFC after: 1 week
Sponsored by: Panzura
For consistency with the qualifiers added in r310977, define a new
qualifier _Null_unspecified which is also defined in clang 3.7+.
Add two new macros:
__NULLABILITY_PRAGMA_PUSH
__NULLABILITY_PRAGMA_POP
These are for use in headers when we want avoid noisy warnings if
some pointers are left without nullability annotations.
These are added with way ahead of their first use to teach the GCC
ports headers of their existance before their first use.
This was meant to be used by a future FORTIFY_SOURCE implementation.
Probably for good, FORTIFY_SOURCE and this particular GCCism were never
well supported by clang or other compilers. Furthermore, the technology
has long since been replaced by either static checkers, sanitizers, or
even just the strong stack protector that was enabled by default.
Drop __gnu_inline to avoid cluttering the headers.
MFC after: 5 days
Add two new qualifiers for use by the static checkers:
_Nonnull
The _Nonnull nullability qualifier indicates that null is not a meaningful
value for a value of the _Nonnull pointer type.
_Nullable
The _Nullable nullability qualifier indicates that a value of the
_Nullable pointer type can be null.
These were introduced in Clang 3.7. For more information, see:
http://clang.llvm.org/docs/AttributeReference.html#nonnull
We add these now without using them so that the GCC ports have time to
pick up the header change.
Hinted by: Android Bionic libc [1]
Also seen in: Apple's Libc-1158.20.4
[1]
baa2a973bd
C99 allows array function parameters to use the static keyword for their
sizes. This tells the compiler that the parameter will have at least the
specified size, and calling code will fail to compile if that guarantee is
not met. However, this syntax is not legal in C++.
This commit reverts r300824, which worked around the problem for
sys/md5.h only, and introduces a new macro: min_size(). min_size(x) can
be used in headers as a static array size, but will still compile in C++
mode.
Reviewed by: cem, ed
MFC after: 4 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D8277
fix a typo in __STDC_VERSION__ in __min_size requirements
MFC after: 1 week
Sponsored by: Panzura
It clashes with the one in libc++'s <atomic> header.
(Previously, the _Atomic() macro was defined in <stdatomic.h>, which is
only for use with C11, but for various reasons it was moved to its
current location in r251804.)
Discussed with: bdrewery, ed
MFC after: 2 weeks
Some architectures like ARM encode the short enum option state in the
object file and the linker checks that this option is consistent for all
objects of an executable. In case applications use -fno-short-enums,
then this leads to linker warnings. Use the enum __packed attribute for
the relevent enums to avoid the -fshort-enums compiler option. This
attribute is at least available on GCC, LLVM/clang and the Intel
compiler.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The locale_t type is provided by <xlocale.h> on Linux, FreeBSD, and Darwin.
While, like on some of those systems, it is automatically included by
<locale.h> with the proper feature test macros, its presence under this
particular name is still presumed in real-world software.
Signed-off-by: Yaakov Selkowitz <yselkowi@redhat.com>
Problem:
After passing locales created by 'duplocale' to 'uselocale',
referencing 'MB_CUR_MAX', which is actually expanded to
'__locale_mb_cur_max()' by preprocessors, causes segmentation faults.
Direct use of locales from 'newlocale' does not cause the problem.
This is the problem of 'duplocale'.
$ echo $LANG
ja_JP.UTF-8
$ cat test.c
#include <stdlib.h>
#include <locale.h>
volatile int var;
int main(void) {
locale_t const loc = newlocale(LC_ALL_MASK, "", NULL);
locale_t const dup = duplocale(loc);
locale_t const old = uselocale(dup);
var = MB_CUR_MAX; /* <-- crashes here */
uselocale(old);
freelocale(dup);
freelocale(loc);
return 0;
}
$ gcc test.c
$ ./a
Segmentation fault (core dumped)
# Note: "core dumped" in the above message was actually written in
# Japanese, but I translated the part to post a mail in English.
Bug:
In the beginning of '__loadlocale' (newlib/libc/locale/locale.c:501),
there is a code which checks if the operations can be skipped:
> /* Avoid doing everything twice if nothing has changed. */
> if (!strcmp (new_locale, loc->categories[category]))
> return loc->categories[category];
While, in the function '_duplocale_r' (newlib/libc/locale/
duplocale.c), '__loadlocale' is called as in the quoted codes:
> /* If the object is not a "C" locale category, copy it. Just call
> __loadlocale. It knows what to do to replicate the category. */
> tmp_locale.lc_cat[i].ptr = NULL;
> tmp_locale.lc_cat[i].buf = NULL;
> if (!__loadlocale (&tmp_locale, i, tmp_locale.categories[i]))
> goto error;
This call of '__loadlocale' results in the skip check being
!strcmp(tmp_locale.categories[i], tmp_locale.categories[i]),
which is always true. This means that the actual operations of
'__loadLocale' will never be performed for 'duplocale'.
Fix:
The call of '__loadlocale' in '_duplocale_r' is modified.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
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.
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
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>
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 adds further comments to nano-mallocr.c, to more comprehensively
explain how padding works in the malloc_chunk structure.
It was originally discussed in the following thread:
https://sourceware.org/ml/newlib/2017/msg00031.html
2017-01-13 Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (malloc_chunk, get_chunk_from_ptr)
(nano_malloc): Add comments.
- use of DEBUG flag is non-standard and interferes with other
project's using same flag
- change to be _REENT_CHECK_DEBUG which means the flag is
allowing debugging of _REENT_CHECK macros
- use #ifdef instead of #if
The pthread_setname_np() and pthread_getname_np() are GNU extensions and
provided by glibc.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
As described in nano-mallocr.c, chunks of heap are represented in memory
as a size (of type long), followed by some optional padding containing a
negative offset to size, followed by the data area.
get_chunk_from_ptr is responsible for taking a pointer to the data area
(as returned by malloc) and finding the start of the chunk. It does this
by assuming there is no padding and trying to read the size, if the size
is negative then it uses that as an offset to find the true size.
Crucially, it reads the padding area as a long.
nano_malloc is responsible for populating the optional padding area. It
does so by casting a pointer to an (int *) and writing the negative
offset into it.
This means that padding is being written as an int but read as a long.
On msp430 an int is 2 bytes, while a long is 4 bytes. This means that 2
bytes are written to the padding, but 4 bytes are read from it: it has
only been partially initialised.
nano_malloc is the default malloc implementation for msp430.
This patch changes the cast from (int *) to (long *). The change to
nano_malloc has has been observed to fix a TI Energia project that
had been malfunctioning because malloc was returning invalid addresses.
The change to nano_memalign is based entirely on code inspection.
I've built and tested as follows:
Configured (gcc+newlib) with: --target=msp430-elf --enable-languages=c
gcc testsuite variations:
msp430-sim/-mcpu=msp430
msp430-sim/-mcpu=msp430x
msp430-sim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either
msp430-sim/-mhwmult=none
msp430-sim/-mhwmult=f5series
My testing has shown no regressions, however I don't know if the gcc
testsuite provides sufficient coverage for this patch?
I don't have write access, so if this patch is acceptable after review,
I would appreciate it if someone would commit it for me.
Thanks,
2017-01-XX Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (nano_malloc): Fix incorrect cast.
(nano_memalign): Likewise.
Add a user-defined name to the self-contained synchronization objects in
order to make system diagnostics, tracing and debugging more user
friendly.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
RTEMS defined SEM_VALUE_MAX to 32767 unlike other systems like FreeBSD
and glibc. A common value is INT_MAX.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
* libc/stdlib/strtod.c (strtof_l): Set errno to ERANGE when double to
float conversion results in infinity.
(strtof): Likewise.
* libc/stdlib/wcstod.c (wcstof_l): Likewise.
(wcstof): Likewise.
__sinit initialises some common file descriptors as line buffered and
relies on the first users of such FDs to call __smakebuf_r. If
__smakebuf_r realises there's no space for a buffer (malloc returns
NULL), it makes them unbuffered. However, while setting the __SNBF
bit, it doesn't clear the __SLBF bit in the flags. Depending on the
order in which functions check buffering flags in the FD, sometime
they assume it's line buffered (e.g. __sfvwrite_r), trashing
application memory that's not really been allocated to them.
This patch solves the problem by clearing the unbuffered/line buffered
flag when setting the line buffered/unbuffered flag.
In the case of memcpy-armv7m.S being built for a big-endian multilib
(including armv7 without a specific profile), realignment code made
assumptions about the byte ordering being little-endian.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
In order to enable proper detection of thread-local storage availability
we have to provide some symbols on ARM.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Turn pthread_spinlock_t into a self-contained object. On uni-processor
configurations, interrupts are disabled in the lock/trylock operations
and the previous interrupt status is restored in the corresponding
unlock operations. On SMP configurations, a ticket lock is a acquired
and released in addition.
See also:
https://devel.rtems.org/ticket/2674
This implementation is simple and efficient. However, this test case of
the Linux Test Project would fail due to call of printf() and sleep()
during spin lock ownership:
https://github.com/linux-test-project/ltp/blob/master/testcases/open_posix_testsuite/conformance/interfaces/pthread_spin_lock/1-2.c
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Provide <memory.h> for all standard Newlib targets and remove
Cygwin-specific header. Most POSIX like systems provide this historic
header.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The non-standard pthread_yield() function is available at least on
Cygwin, FreeBSD and glibc.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
This makes it possible provide operating system specific types for
<pthread.h>. It is in line with the FreeBSD header file structure and
allows a future cleanup of <pthread.h> to not expose unrelated things
via <sys/types.h> and <unistd.h>. Glibc uses the similar
<bits/pthreadtypes.h> for this purpose.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Add _TICKET_LOCK_INITIALIZER to statically initialize a
_Ticket_lock_Control structure. This makes it possible to embed a
ticket lock in other structures outside of <sys/lock.h>.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Non-default visibility attributes are unsupported on PE/COFF, so don't
use in __hidden definition for Cygwin. Add comment.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The FreeBSD kernel types are not used in Newlib. Provide them via an
external header file to decouple Newlib and FreeBSD updates for RTEMS.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Hi,
make pdf on Ubuntu 16.04 fail with:
newlib/libc/libc.texinfo:9: Missing @endcsname inserted.
After a lot of fiddling the reason appears to be the combination of concept
and function index despite a lack of concept index entries. Arguably texinfo
should not error in that case but here we are, newlib will fail to build its
documentation on some systems because of this. Since libc.texinfo only
contains function index entries this patch simply removes the combination of
indices. It does the same for libm.texinfo which has concept index entries but
no function index entries.
Tested by running make pdf, make dvi, make info and make html successfully.
libc.pdf appears to have only one index as expected.
== Proposed commit message ==
Fix pdf build failure with texinfo 6.1.0 as provided in Ubuntu 16.04. Index
combination in libc.texinfo and libm.texinfo fails because both file have only
one type of index entries. Removing index combination is thus harmless and
solves the problem.
Is this ok for master?
Best regards,
Thomas
Provide __intmax_t and __uintmax_t via <machine/_default_types.h> and
define intmax_t and uintmax_t in <sys/_stdint.h> for FreeBSD
compatibility.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Dionna Glaze
Sebastian Pop
Yaakov Selkowitz
Thomas Preud'homme
Corinna Vinschen
Sebastian Huber
Silviu Baranga
Prakhar Bahuguna
Kito Cheng
Jeff Johnston
imp
cem
mckusick
hselasky
lstewart
avg
pfg
asomers
dim
Catherine Moore
Joel Sherrill
Koichi Murase
Freddie Chopin
Kyrill Tkachov
Pat Pannuto
Thomas Preudhomme
Eric Blake
Gedare Bloom
Joe Seymour
Julian Brown
Douglas