| Age | Commit message (Collapse) | Author |
|---|
|
Fix the [-Warray-parameter=] warning for __sigsetjmp generated by GCC 11 and
later GCC versions:
|
| warning: argument 1 of type 'struct __jmp_buf_tag *' declared as a pointer [-Warray-parameter=]
| extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROWNL;
| ...
| note: previously declared as an array 'struct __jmp_buf_tag[1]'
| extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask)
|
Use the same fix as in glibc. The fix is to move the struct __jmp_buf_tag
definition to a separate bits/ header so it can be included in
pthread.h, to allow to use an array (as in setjmp.h) rather than a pointer
in the declaration.
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Commit 95e38b37 ("add support for systems without legacy setrlimit/getrlimit
syscalls") has added use of the prlimit64 syscall in getrlimit and setrlimit
functions. This change causes memory corruption on getrlimit call for 32-bit
CPUs like ARC, as ARC doesn't have ugetrlimit syscall and uses prlimit64.
Also, setrlimit has been broken by prlimit64 call on 32-bit CPUs like, i386,
ARM, ARC.
For the prlimit64 syscall the kernel expects an rlimit struct with 64-bit fields,
but on 32-bit CPUs without _FILE_OFFSET_BITS=64 the struct rlimit has 32-bit
fields.
Add safe implementations of getrlimit, setrlimit, prlimit for 32-bit CPUs with a
local struct rlimit64 variable for use in the prlimit64 syscall.
For 64-bit CPUs and configurations with _FILE_OFFSET_BITS=64 use
getrlimit, setrlimit, prlimit as aliases to getrlimit64, setrlimit64 and
prlimit64. Add a new function prlimit64.
Tested on aarch64, arm, i386, arc.
Fixes: 95e38b37 ("add support for systems without legacy setrlimit/getrlimit syscalls")
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Fixes compilation issues on mips64 n32.
|
|
|
|
fork() can be implemented using either the fork or clone syscalls on MMU
systems. Therefore the stub is only generated if neither __NR_fork nor
__NR_clone are defined. The stub code manually undefines __NR_fork on
no-MMU systems in an attempt to enable the stub, but this doesn't work
because __NR_clone is still defined. It is not appropriate to undefine
__NR_clone because clone is available on no-MMU, it is just not capable
of implementing fork.
This patch directly enables the fork stub if __ARCH_USE_MMU__ is not
defined. This eliminates the need to undefine __NR_fork, so this code is
removed
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
|
|
Previously kvx assembler considered all separators (",", "?", "=", "[]")
to be the same, this is not the case anymore hence we need to fix all
the misformed assembly.
Signed-off-by: Paul Iannetta <piannetta@kalray.eu>
Acked-by: Yann Sionneau <ysionneau@kalray.eu>
Tested-by: Yann Sionneau <ysionneau@kalray.eu>
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Use a custom stat.h header for kvx arch.
This makes sure it is aligned with Linux kernel one.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Define that kvx Linux port supports statx syscall.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Align the specification of the ptrace interface with how it is specified on RISC-V.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Add fstatat wrapper that uses statx for non-legacy arch.
This allows non-legacy arch to opt-out from defining the old stat* syscalls
by not defining __ARCH_WANT_NEW_STAT in their
arch/xxx/include/asm/unistd.h
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Those must have the recent prlimit64 syscall which exists since
Linux 3.2.
This patch is necessary for non-legacy architectures that wish to remove
support for legacy setrlimit/getrlimit syscalls.
The non-legacy arch are those who opt-out via non defining
__ARCH_WANT_SET_GET_RLIMIT in their arch/xxx/include/uapi/asm/unistd.h
setrlimit and getrlimit are then emulated via the new prlimit64 syscall.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
Add missing return value statement to fstat for the statx wrapping case.
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
fstatat64 syscall
Define fstatat64 as a wrapper of statx if the kernel does not support fstatat64 syscall
This is the case for non-legacy architectures that don't define __ARCH_WANT_NEW_STAT
in their linux arch/xxx/include/asm/unistd.h
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
The commit cf649082c7d4 ("remove forced gcc optimization") removed -O3
optimization specified in the code for the function _fork_parent, but at
the same time it removed the 'static inline' part of the function
definition. That change seems unintended and _fork_parent is not a part
of the libc interface. Make it static inline again.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
issue with gcc 12
The current definition of __WCHAR_MIN and __WCHAR_MAX are only correct
when wchar_t is an int. This is not the case on ARM/AArch64 where
wchar_t is an unsigned int, or some other architectures where wchar_t
is a long.
The current incorrect definition causes a build issue for example when
building mpd, which uses boost, with gcc 12.x:
In file included from /home/thomas/buildroot/aarch64/host/aarch64-buildroot-linux-uclibc/sysroot/usr/include/boost/integer.hpp:20,
from /home/thomas/buildroot/aarch64/host/aarch64-buildroot-linux-uclibc/sysroot/usr/include/boost/crc.hpp:42,
from ../src/storage/StorageState.cxx:43:
/home/thomas/buildroot/aarch64/host/aarch64-buildroot-linux-uclibc/sysroot/usr/include/boost/integer_traits.hpp:105:69: error: narrowing conversion of ‘-2147483648’ from ‘int’ to ‘wchar_t’ [-Wnarrowing]
105 | public detail::integer_traits_base<wchar_t, WCHAR_MIN, WCHAR_MAX>
| ^
This issue was fixed in glibc in 2013, see bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=15036, and upstream
commit
https://sourceware.org/git/?p=glibc.git;a=commit;h=052aff95782fefe9c63566471063e8b20836bfb8.
Since the i386-specific definition of __WCHAR_MIN and __WCHAR_MAX was
also removed at the same time in glibc, we do the same as part of this
commit.
Reported-by: Clément Ramirez <clement.ramirez@bootlin.com>
With-some-useful-help-from: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
|
|
|
|
|
|
See here for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=28509
|
|
Added definition for MAP_FIXED_NOREPLACE which was added in kernel 4.17
Signed-off-by: linted <linted@users.noreply.github.com>
|
|
|
|
|
|
|
|
on MIPS.
Signed-off-by: Evgeniy Manachkin <sfstudio@wi-cat.ru>
|
|
Added 32-bit RISC-V support. I have managed to get 32-bit RISC-V No-MMU
Linux running based on mainstream buildroot. It's nice to have uclibc
support this 32-bit No-MMU target.
There's no substantial code change except definations and config
options.
Signed-off-by: Yimin Gu <ustcymgu@gmail.com>
|
|
Modified config files and crt1.S to support static pie elf generation.
Signed-off-by: linted <linted@users.noreply.github.com>
|
|
Add ability to use optimized versions of string functions for ARCv3 32-bit
CPUs with UCLIBC_HAS_STRING_ARCH_OPT option. Add optimized
memcpy/memset/memcmp code for ARCv3 CPUs based on the code from newlib
and adapt for ARCv3 existed optimized strchr/strcmp/strcpy/strlen.
Link to the Synopsys newlib repo with code for ARCv3 on GitHub:
https://github.com/foss-for-synopsys-dwc-arc-processors/newlib
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
New ARCv3 ISA includes both 64-bit and 32-bit CPU family.
This patch adds support for 32-bit ARCv3 HS5x processors.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Add a header file with assembler macros to be able to handle in one
place the differences between ARCv2 and ARCv3 ISAs. It is a preparatory
step before the introduction of support for ARCv3 CPUs.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich@synopsys.com>
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
When uclibc is built with static PIE support the _dl_load_base variable
shared between the libc-tls.c and reloc_static_pie.c creates the
dependency that requires linking reloc_static_pie.o into static
position-dependent executables resulting in the following build errors:
gcc -static test.c -o test
...ld:
...usr/lib/libc.a(reloc_static_pie.os):(.text+0x0):
undefined reference to `_DYNAMIC'
Move _dl_load_base definition to libc-tls.c to resolve this dependency
and fix static PDE build.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
on mips
Updated config to allow compilation of rcrt1.o for mips and modified it's crt1.S to perform relocates in __start.
The mips architecture performs relocations differently then most other architectures. reloc_static_pie was rewritten, taking code from dl-startup.c, in order to perfrom the additional relocations. Modifications were made to mips' dl-startup.h to allow for the use of contained macros without including _start definition.
Signed-off-by: linted <linted@users.noreply.github.com>
|
|
on aarch64
Updated config to allow compilation of rcrt1.o for aarch64 and modified it's crt1.S to relocate dynamic section prior to __uClibc_main.
Disabled stack protector when compiling reloc_static_pie.c to avoid TLS access prior to it being setup.
Signed-off-by: linted <linted@users.noreply.github.com>
|
|
There is a real-world usage of RUSAGE_THREAD by the pistache project,
https://github.com/oktal/pistache.
Reported-By: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
|
|
on i386, x86_64, and arm.
This patch adds the generation of rcrt1.o which is used by gcc when compiling with the --static-pie flag.
rcrt1.o differs from crt1.o and Scrt1.o in that it the executable has a dynamic section but no relocations have been performed prior to _start being called.
crt1.o assumes there to be no dynamic relocations, and Scrt1.o has all relocations performed prior to execution by lsdo.
The new reloc_static_pie function handles parsing the dynamic section, and performing the relocations in a architecture agnostic method.
It also sets _dl_load_base which is used when initalizing TLS to ensure loading from the proper location.
This allows for easier porting of static-pie support to additional architectures as only modifications to crt1.S to find the load address are required.
Signed-off-by: linted <linted@users.noreply.github.com>
|
|
Implement getcontext, makecontext, setcontext and swapcontext.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
getaddrinfo() returns addresses from, at least, ip(7) and ipv6(7),
but _addr() always uses sin_addr from struct sockaddr_in;
we're saved from wild unsoundness (or incompatibility)
by virtue of struct sockaddr_in6 having an always-0 u32 sin6_flowinfo
at the same offset, so we end up returning 0 anyway,
but in a round-about and definitely unintended way
Instead, limit the request to AF_INET, and fall through to the end
early, returning the default id=0
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
|
|
Explicitly include stdint header as logic uses INT[64]_MAX, just
in case for future, even though the chain of headers from existing
includes brings in the definition indirectly as of now.
Cross check for time gap between prngplus reseeding, periodically,
has the internal state is being consumed, so that if there is too
much time gap, then prng reseeding can be forced, before the normal
reseed window is reached. This is useful for long running programs
which trigger dns queries only intermittently.
If clock_gettime is not available, then reseed more frequently, by
default. A platform developer may change the reseed frequence, to
be bit more less often in this case, if needed, by tweaking the
defines in the source.
Signed-off-by: hanishkvc <hanishkvc@gmail.com>
|
|
This borrows getloadavg.c from musl.
getloadavg pops up often. Recently llvm and rust are dependent on it.
glibc and musl have it and no-one actually checks if it's available in your libc.
It's just become way easier to add it in uclibc-ng rather than patch everything else.
Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
|
|
This macro exists since Linux 2.6.25 [1] and is defined in glibc
since 2.14 [2] for sparc and most supported architectures.
RLIMIT_RTTIME has been added later for mips [3] and alpha [4].
For example, RLIMIT_RTTIME is needed to build qemu 7.0.0 with
Linux user-land emulation support [5].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=78f2c7db6068fd6ef75b8c120f04a388848eacb5
[2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=67f86a251e0d36107fe28999281d46e76941c7b9
[3] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8969f4df1a526aa60dd0bc1c4736cf02104d4a05
[4] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=53c2cb7641bd866398156625ef672bbd2d78a0d8
[5] https://git.qemu.org/?p=qemu.git;a=commitdiff;h=244fd08323088db73590ff2317dfe86f810b51d7
Signed-off-by: Romain Naour <romain.naour@gmail.com>
|
|
Dns lookup logic has been updated to provide a configurable compile
time selection of dns query id generation logics, including random,
where possible, instead of the previous simple counter mode.
This should make dns poison attempts more difficult. The uclibc
developers wish to thank the white hat teams which alerted the
community about the possible weakness in the dns path, given the
increased resources with adversaries today.
Given that embedded systems may or may not have sources for trying
to generate random numbers, and also to try and keep the load on
the system low, by default it uses the standard random prng based
logic to indirectly generate the ids.
However if either urandom or else if realtime clock is available on
the target, then the same is used to reseed the prng periodically
in a slightly non deterministic manner. Also additional transform
(one way where possible) is used to avoid directly exposing the
internal random sequence.
The dns lookup logic maintains its own state wrt the random prng
functions, so that other users of the library's random prng are
not affected wrt their operations with the prng.
Note to Platform developers:
If you want to change from the default prngplus based logic, to one
of the other logics provided, then during compile/config time you can
switch to one of these additional choices wrt dns query id generation,
by using make config and companions.
If your platform doesnt support urandom nor a realtime clock backed
by a source with sufficient resolution, and or for some reason if you
want to revert to previous simple counter, rather than the transformed
random prng plus logic, you can force the same at compile time by
selecting SimpleCounter mode.
If you want to increase the randomness of the generated ids, and dont
mind the increased system load and latency then you could select the
Urandom mode during config. Do note that it will be dipping into the
entropy pool maintained by ur system.
If your target has a system realtime clock available and exposed to
user space, and inturn if you want to keep the underlying logic simple,
you could try using the clock option from the config. However do note
that the clock should have nanosecond resolution to help generate ids
which are plausibly random. Also improvements to processor and or io
performance can affect this.
Wrt the URandom and Clock modes, if there is a failure with generation
of the next random value, the logic tries to fallback to simple counter
mode.
If you want to change the underlying logic to make it more random
and or more simple, look at dnsrand_setup and dnsrand_next.
Signed-off-by: hanishkvc <hanishkvc@gmail.com>
|
|
The ARM implementation of memset has a bug when the fill-value is negative or outside the
[0, 255] range. To reproduce:
char array[256];
memset(array, -5, 256);
This is supposed to fill the array with int8 values -5, -5, -5, ... . On ARM, this does
not work because the implementation assumes the high bytes of the fill-value argument are
already zero. However in this test case they are filled with 1-bits. The aarch64 and x86_64
implementations do not have this problem: they first convert the fill-value to an unsigned
byte following the specification of memset.
With GCC one can use `memset(ptr, (-5 & 0xFF), size)` as a workaround, but for clang
users that does not work: clang optimizes the `& 0xFF` away because it assumes that
memset will do it.
Signed-off-by: Tom Bannink <tombannink@gmail.com>
Acked-by: Peter Korsgaard <peter@korsgaard.com>
|
