| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The Linux kernels ELF-FDPIC binfmt program loader can support loading and
running conventional ELF format binaries on noMMU kernels when compiled
appropriately. That is when they are constant displacement binaries such
as generated using the -pie compile option.
Add a configure option to allow selecting ELF binary support in noMMU
mode configurations on architectures that support this. The main
requirement is to generate the ldso run-time loader to perform relocation
at load time. These configurations do not support shared libraries, so
there is no need to generate a full shared library, only the static
version is required.
The use of ELF format binaries does mean a slightly simpler toolchain
generation (does not require a -uclinux- for some architectures) and does
not require an extra tool like elf2flt.
This initial support targets M68K, ARM and RISC-V architectures. No kernel
changes are required, the required support for this is already in mainline
kernels (certainly as of linux-6.6).
Note that for the M68K and ARM architectures that the initialized
registers and stack layout at process startup is slightly different for
the flat format loader and the ELF/ELF-FDPIC loaders. So we need some
changes to the startup code (crt1.S) for them.
I have not done extensive testing outside of M68K, ARM and RISC-V.
I had to make changes to a couple of the dl-startup.h architecture files
to get them to build for this noMMU case. I did not dig down too deep on
the reasons, but they still seem ok for the MMU case as well.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
The spurious_wakeup_count variable is set but is never actually used for
the semaphore implementation. To avoid a clang warning for this case
remove the unused variable.
|
|
When compiling getaddrinfo.c with clang the -Wmisleading-indentation
option will cause a warning due to the indentation lining up with the
previous statement in the if block above.
For gcc the warning is blinded by the commented line. See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107162
Move the comment behind the function call to make both compilers happy.
|
|
Linux kernel returns -1ULL as RLIM64_INFINITY for all cpus.
Fix RLIM64_INFINTIY and 64-bit variant of RLIM_INFINITY macro for
sparc, mips, alpha, as for these CPUs the library uses different
value than what the kernel sets and it can cause incorrect
RLIM64_INFINTY check.
Because alpha is a 64-bit arch, fix the RLIM_INFINITY macro twice
(the value should be the same with and without __USE_FILE_OFFSET64
definition) to match the prlimit64 syscall in the kernel.
Previous implementation of setrlimit/getrlimit functions didn't use
prlimit64 syscall and didn't receive RLIM64_INFINTIY from the kernel,
RLIM64_INFINTY macro was used by the library itself to mimic the
64-bit rlimit in the getrlimit64/setrlimit64 functions, that allowed
to have RLIM64_INFINTIY different from what the kernel sets.
New implementation of setrlimit/getrlimit uses prlimit64 and checks
for RLIM64_INFINITY value and must have equal RLIM64_INFINITY
definition with what the kernel uses.
This issue is indicated by the tst-rlim/tst-rlim64 tests
on sparc/mips32/alpha, tests return 23 (UNSUPPORTED) because of
incorrect RLIM_INFINTY check for available rlimit type.
This patch will require rebuild of sparc/mips32/alpha binaries that
explicitly use RLIM64_INFINTY or 64-bit variant of RLIM_INFINITY
(if binary for 32-bit CPU was built with _FILE_OFFSET_BITS=64) to
update the macro value.
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
In certain cases, fnmatch() could access the next byte beyond the end of
he passed pattern. A triggering pattern to match is the following
invocation:
fnmatch("[A-Z[.", "F", 0)
The normal A-Z group match gets us to fnmatch_loop.c:421 and then to
fnmatch_loop:599. The F in the filaname matches this expression and
we end up in fnmatch_loop:867 which handles skipping the rest of a
bracked expression that already matched. Here we enter the case where
the next chars to parse are a collating symbol starting with "[."
(fnmatch_loop:918). Currently the p pointer is then advanced by one,
moving it beyond the "." and to the \0 byte of the pattern string
(fnmatch_loop:920). Inside the while loop the pointer is then
incremented again and immediately dereferenced, reaching beyond the
end of the pattern string.
The increment before the while loop must be removed, because only inside
the while loop (after the other increment) a check for the end of the
string is performend. This is sufficient and the check of the end of
the collating symbol is only performed if p[1] is at most the
terminating \0 byte.
Signed-Off-By: Frank Mehnert <frank.mehnert@kernkonzept.com>
|
|
Remove read ahead in the per-word compare loop as it can cause a
segmentation fault in certain circumstances (when a string crosses a
page boundary). For baremetal this relaxed approach is suitable but
in Linux with MMU we should be more restrictive.
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Add acquire/release variants for atomic functions cmpxchg/xchg and
provide a memory barrier after/before exchange. For cmpxchg use compiler
builtins. For xchg functions add memory barrier explicitly.
These barriers are required to keep memory consistency of ARCv3 CPU
cores in SMP.
For ARC700 barriers are not required and the compiler doesn't provide
_atomic_compare_exchange*, use current asm insertion without
acquire/release variants for ARC700.
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
The tst-rlimit/tst-rlimit64 tests pointed to several issueses in
prlimit() function for 32-bit CPUs. This patch adds name redirection to
prlimit64 in prlimit declaration to provide correct support for 64-bit
offset (_FILE_OFFSET_BITS=64) on 32-bit CPUs and fixes improper field
assignment and incorrect syscall paramerets in the prlimit() function.
Fixes: 8c2f6218 ("setrlimit/getrlimit: fix prlimit64 syscall use for 32-bit CPUs")
Signed-off-by: Pavel Kozlov <pavel.kozlov@synopsys.com>
|
|
Threads currently have 2-4 MiB stacks by default (depending on the
platform). This is fine on MMU platforms, where this stack space is not
actually allocated until it is used, but tends to waste a large amount
of memory on no-MMU platforms.
This patch adds a PTHREADS_STACK_DEFAULT_SIZE Kconfig option that allows
the user to override the default stack size at build time. This allows
the user to select a reasonable default stack size for the software that
runs on their system, and avoids the need to patch every package to add
calls to pthread_attr_setstacksize().
An alternative to this patch would be to change the hardcoded default
stack size on no-MMU platforms, but it is difficult to choose an
appropriate value because the minimum required stack depends on the
software in use. This would also be a breaking change.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
|
|
Commit 21cbb6fe ("unistd.h: put getppid under XOPEN2K8") introduced a
new __THROWNL specification for non-leaf throws. It also made use of
these in the setjmp.h header. The functions that use this specification
(longjmp and siglongjmp) have their extern __libc__* equivalent
definition prototype specified using __typeof__ for the internal
function signatures. For C++ this copies the throw() specifier, since
this is part of the type for C++. The attribute in C is not.
This commit explicitly types out the signature for the two functions to
be compatible between the C++ and C worlds.
An alternative would be to keep the __typeof__ declaration and use
the copy attribute. Then the __THROWNL part could be thrown out since
the C attribute would be copied and the C++ exception specifier would
be part of the signature from __type__. However, since the copy
attribute is not supported for all compilers supported by uclibc-ng
this is not viable at this time.
|
|
elf-fdpic.h is included by link.h. When a C++ program includes <link.h>,
we get the following build failure:
<...>/usr/include/bits/elf-fdpic.h: In function ‘void* __reloc_pointer(void*, const elf32_fdpic_loadmap*)’:
<...>/usr/include/bits/elf-fdpic.h:94:54: error: invalid use of ‘void’
94 | unsigned long offset = p - (void*)map->segs[c].p_vaddr;
| ^~~~~~~
void pointer addition and subtraction is not allowed in C++ as it has
undetermined size, however in C with language extension it is possible
because sizeof void is treated as one byte.
This patch was previously applied to Blackfin, FR-V and C6x, but not
ARM.
Signed-off-by: Ben Wolsieffer <ben.wolsieffer@hefring.com>
|
|
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.
|
|
|
|
Fixes segfaults in curl with gnutls encryption.
|
|
|
|
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>
|
|
The only difference, with regard to libc, is the compile flag: -march=
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes haveged compile issues in OpenADK and buildroot when
a static toolchain is used.
|
|
|
|
Setting signal handler in the kernel and then updating sighandler[sig]
results in a crash if a signal which handler is being changed from
SIG_DFL to a non-default was pending. Improve the race a little and
update the sighandler[sig] before the sigaction syscall. It doesn't
eliminate the race entirely, but fixes this particular failing case.
E.g. this fixes the 100% reproducible segfault in the busybox hush shell
built with FEATURE_EDITING_WINCH on ssh client's terminal window resize,
but in that case there's one more even bigger issue: busybox calls
sigaction with both old and new signal pointers pointing to the same
structure instance, as a result act->sa_handler after the sigaction
syscall is not what the user requested, but the previous handler.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
|
|
DES tables take up a huge amount of space in the .bss and they aren't
even variable. Generate constant tables and put them into des_tables.c
and drop constants and code used to generate them from des.c
This saves ~70KBytes of the .bss and ~3KBytes of the total library size:
text data bss dec hex filename
- 618508 25652 89400 733560 b3178 lib/libuClibc-1.0.42.so
+ 685664 25672 19488 730824 b26c8 lib/libuClibc-1.0.42.so
Modified libc passes the DES validation suite from the uclibc-ng-test.
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>
|
|
For instance with buildroot config sipeed_maix_bit_defconfig the pre-processor generates
if (1)
r = ({ long _sys_result; { register long int _a7 __asm__ ("a7"); register long _a3 __asm__ ("a3"); long _a3tmp; register long _a2 __asm__ ("a2"); long _a2tmp; register long _a1 __asm__ ("a1"); long _a1tmp; long _a0tmp; register long _a0 __asm__ ("a0"); _a0tmp = (long) (clock_id); _a0 = _a0tmp; _a1tmp = (long) (flags); _a1 = _a1tmp; _a2tmp = (long) (req); _a2 = _a2tmp; _a3tmp = (long) (rem); _a3 = _a3tmp; _a7 = (115); __asm__ volatile ( "scall\n\t" : "=r" (_a0) : "r"(_a7) , "r" (_a0), "r" (_a1), "r" (_a2), "r" (_a3) : "memory"); _sys_result = _a0; } _sys_result; });
else
{
int oldstate = LIBC_CANCEL_ASYNC ();
r = ({ long _sys_result; { register long int _a7 __asm__ ("a7"); register long _a3 __asm__ ("a3"); long _a3tmp; register long _a2 __asm__ ("a2"); long _a2tmp; register long _a1 __asm__ ("a1"); long _a1tmp; long _a0tmp; register long _a0 __asm__ ("a0"); _a0tmp = (long) (clock_id); _a0 = _a0tmp; _a1tmp = (long) (flags); _a1 = _a1tmp; _a2tmp = (long) (req); _a2 = _a2tmp; _a3tmp = (long) (rem); _a3 = _a3tmp; _a7 = (115); __asm__ volatile ( "scall\n\t" : "=r" (_a0) : "r"(_a7) , "r" (_a0), "r" (_a1), "r" (_a2), "r" (_a3) : "memory"); _sys_result = _a0; } _sys_result; })
;
LIBC_CANCEL_RESET (oldstate);
}
And also the compiler issues these warnings:
librt/clock_nanosleep.c: In function 'clock_nanosleep':
librt/clock_nanosleep.c:43:22: warning: implicit declaration of function
'LIBC_CANCEL_ASYNC'; did you mean 'LIBC_CANCEL_HANDLED'?
[-Wimplicit-function-declaration]
43 | int oldstate = LIBC_CANCEL_ASYNC ();
| ^~~~~~~~~~~~~~~~~
| LIBC_CANCEL_HANDLED
librt/clock_nanosleep.c:48:7: warning: implicit declaration of function
'LIBC_CANCEL_RESET'; did you mean 'LIBC_CANCEL_HANDLED'?
[-Wimplicit-function-declaration]
48 | LIBC_CANCEL_RESET (oldstate);
| ^~~~~~~~~~~~~~~~~
| LIBC_CANCEL_HANDLED
So if the compiler is a bit picky and does not optimize the if (1) {} else {} it can fail to link with undefined symbols.
This patch fixes this issue: no more warning.
Btw, that's the solution that is already used in the following cancellation point files:
* libc/sysdeps/linux/common/__syscall_fcntl.c
* libc/sysdeps/linux/common/__syscall_fcntl64.c
* libc/sysdeps/linux/common/ioctl.c
* libc/sysdeps/linux/common/openat.c
* libc/sysdeps/linux/common/open.c
Signed-off-by: Yann Sionneau <yann@sionneau.net>
|
|
This reverts commit 08d46f1ce21e4ec51b2b1626beeaea6cbe7fdc6b.
Signed-off-by: Yann Sionneau <yann@sionneau.net>
|
