summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-29libc: restore correct definition of semid_ds struct.Dmitry Chestnykh
Previously the common definition of this structure was broken by a mistake. Restore it correctly for all needed architectures and all use cases. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-29Add time64 support for sparc.Dmitry Chestnykh
By some reason sparc ld.so cannot work properly with statx() system call, so fallback to regular stat() family in ld.so. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-28Add time64 support to OpenRISC.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-28libc: Pass 64bit-only time structures to syscalls.Dmitry Chestnykh
With time64 enabled we need to pass structure which consists of two 64bit fields to clock_gettime64() and clock_nanosleep_time64() syscalls with proper conversion to regular timespec structure after syscall execution. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-28libc: always redirect *stat() family to statx() with time64 enabled.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-28ldso: Use statx() when time64 is enabled.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-27Fix *stat() and *stat64() when the time is beyond year 2038.Dmitry Chestnykh
To obtain correct `st_atim`, `st_mtim` and `st_ctim` fields we need to use statx() syscall and then convert the data from the kernel to the regular stat structure. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-26Add time64 support for MIPS32.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-26Refactor `ts32_struct` and `TO_ITS64_P`.Dmitry Chestnykh
- Renamed `ts32_struct` to `__ts32_struct` like `__ts64_struct` and moved its definition to the header. - Removed extra space from TO_ITS64_P() macro. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-25Add time64 support for PowerPC.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-25Add support for using time64 on big-endian machines.Dmitry Chestnykh
For BE architectures there is one significant difference in comparison with time64 support for little-endian architectures like ARMv7. The difference is that we strictly need to pass two 64bit values to system calls because Linux Kernel internally uses `struct __kernel_timespec` and similar, which consists of two 64bit fields. For this reason many files have been changed to convert pointers to timespec-family structures (mixed of 64bit and 32bit values) to the pointer of the similar but 64bit-only structures for using as system calls args. This is general prerequisite for any BE architecture. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-25Remove unneeded comparisons.Dmitry Chestnykh
Inside `if` branches the conditions `as->ino == bs->ino` and `as->dev == bs->dev` are always false. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-25ldso: Remove unneeded semicolons.Dmitry Chestnykh
We use semicolons in the place of `DL_RELOCATE_RELR()` and `DL_DO_RELOCATE_RELR()` 'calling' so the semicolon in the macro definition leads to semicolon duplication after preprocessing. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-22xtensa: Add time64 support.Dmitry Chestnykh
- xtensa is the second architecture that supports time64 inside uClibc-ng. - Linux Kernel always uses 32bit time variables inside `stat` structures, so there is a need to use `st_atime`, `st_mtime` and `st_ctime` structures with the same 32bit-wide `tv_sec` and `tv_nsec` variables even if time64 is enabled. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-22Introduce time64 support.Dmitry Chestnykh
This patch introduces *time64 syscalls support for uClibc-ng. Currently the redirection of syscalls to their *time64 analogs is fully supported for 32bit ARM (ARMv5, ARMv6, ARMv7). The main changes that take effect when time64 feature is enabled are: - sizeof(time_t) is 8. - There is a possibility os setting date beyond year 2038. - some syscalls are redirected: clock_adjtime -> clock_adjtime64 clock_getres -> clock_getres_time64 clock_gettime -> clock_gettime64 clock_nanosleep -> clock_nanosleep_time64 clock_settime -> clock_settime64 futex -> futex_time64 mq_timedreceive -> mq_timedreceive_time64 mq_timedsend -> mq_timedsend_time64 ppoll -> ppoll_time64 pselect6 -> pselect6_time64 recvmmsg -> recvmmsg_time64 rt_sigtimedwait -> rt_sigtimedwait_time64 sched_rr_get_interval -> sched_rr_get_interval_time64 semtimedop -> semtimedop_time64 timer_gettime -> timer_gettime64 timer_settime -> timer_settime64 timerfd_gettime -> timerfd_gettime64 timerfd_settime -> timerfd_settime64 utimensat -> utimensat_time64. - settimeofday uses clock_settime (like in glibc/musl). - gettimeofday uses clock_gettime (like in glibc/musl). - nanosleep uses clock_nanosleep (like in glibc/musl). - There are some fixes in data structures used by libc and kernel for correct data handling both with and without enabled time64 support. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-20Replace null subtraction with castSven Linker
Clang warns about null-pointer subtractions, which are undefined behavior per the C standards. Replace the subtractions with explicit casts to `uintptr_t`.
2024-02-20libc: Fix some unused parameter warningsSven Linker
2024-02-20Remove duplicate semicolonsMarcus Haehnel
While they are not a problem per-se they cause issues with some tooling (such as clang coverage) and are confusing to the reader.
2024-02-20ldso: add null-pointer checkFrank Mehnert
There is a check for (*rpnt == NULL) a few lines above but the "else" case performing an allocation does only exist if SHARED is not defined. If SHARED is defined, the allocation is not performed and it may happen (at least in theory) that *rpnt == NULL when executing (*rpnt)->dyn = tpnt; Add the null-pointer check. Signed-off-by: Frank Mehnert <frank.mehnert@kernkonzept.com>
2024-02-20fix c6x toolchain compileWaldemar Brodkorb
2024-02-19Rename `reloc_addr` to suppress `-Wshadow` warning.Dmitry Chestnykh
Here is the warning: ldso/ldso/dl-elf.c: In function '_dl_fixup': ./ldso/include/dl-elf.h:259:37: warning: declaration of 'reloc_addr' shadows a previous local [-Wshadow] 259 | ElfW(Addr) *reloc_addr = 0; \ | ^~~~~~~~~~ ./ldso/include/dl-elf.h:290:33: note: in expansion of macro 'DL_DO_RELOCATE_RELR' 290 | DL_DO_RELOCATE_RELR(dyn->loadaddr, relr_start, relr_end); \ | ^~~~~~~~~~~~~~~~~~~ ldso/ldso/dl-elf.c:1032:9: note: in expansion of macro 'DL_RELOCATE_RELR' 1032 | DL_RELOCATE_RELR(tpnt); | ^~~~~~~~~~~~~~~~ In file included from ldso/ldso/ldso.c:1462: ldso/ldso/dl-elf.c:1012:20: note: shadowed declaration is here 1012 | ElfW(Addr) reloc_addr Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-18Fix broken compilation of uClibc-ng.Dmitry Chestnykh
During buildroot compilation with latest uClibc I've encoutered linking error due to multiple definition of some symbols from DNS code. The error happens because the same file resolv.c is included inside many other .c files: res_comp.c:(.text+0x0): multiple definition of `__GI___dn_expand'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x8a0): first defined here res_comp.c:(.text+0x0): multiple definition of `__dn_expand'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x8a0): first defined here res_comp.c:(.text+0x34): multiple definition of `__GI___dn_comp'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xc68): first defined here res_comp.c:(.text+0x34): multiple definition of `__dn_comp'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xc68): first defined here ns_name.c:(.text+0x4c): multiple definition of `__GI___ns_name_ntop'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x4c): first defined here ns_name.c:(.text+0x4c): multiple definition of `__ns_name_ntop'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x4c): first defined here ns_name.c:(.text+0x1f8): multiple definition of `__GI___ns_name_pton'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x1f8): first defined here ns_name.c:(.text+0x1f8): multiple definition of `__ns_name_pton'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x1f8): first defined here ns_name.c:(.text+0x624): multiple definition of `__hnbad'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x624): first defined here ns_name.c:(.text+0x718): multiple definition of `__GI___ns_name_unpack'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x718): first defined here ns_name.c:(.text+0x718): multiple definition of `__ns_name_unpack'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x718): first defined here ns_name.c:(.text+0x84c): multiple definition of `__GI___ns_name_uncompress'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x84c): first defined here ns_name.c:(.text+0x84c): multiple definition of `__ns_name_uncompress'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x84c): first defined here ns_name.c:(.text+0x8a0): multiple definition of `__GI___ns_name_pack'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x8d4): first defined here ns_name.c:(.text+0x8a0): multiple definition of `__ns_name_pack'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0x8d4): first defined here ns_name.c:(.text+0xbe4): multiple definition of `__GI___ns_name_compress'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xc18): first defined here ns_name.c:(.text+0xbe4): multiple definition of `__ns_name_compress'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xc18): first defined here ns_name.c:(.text+0xc34): multiple definition of `__GI___ns_name_skip'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xcdc): first defined here ns_name.c:(.text+0xc34): multiple definition of `__ns_name_skip'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xcdc): first defined here ns_name.c:(.text+0xcd4): multiple definition of `__GI___dn_skipname'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xd7c): first defined here ns_name.c:(.text+0xcd4): multiple definition of `__dn_skipname'; libc/libc_so.a(encodeq.os):encodeq.c:(.text+0xd7c): first defined here My previous commit that fixes build error of DNS code is okay, but there are some 'bottlenecks' in uClibc-ng code, so if we don't want to completely rewrite resolv.c we need to make some symbols weak to prevent linking errors.
2024-02-18Avoid fall-through if file matching temporary name existsSven Linker
During checking whether a temporary name can be created, it may happen that a file with this name already exists. Avoid falling through to opening the file name in this case, and return with an error instead. Signed-off-by: Sven Linker <sven.linker@kernkonzept.com>
2024-02-18Add extra `-shared` to link.so command.Dmitry Chestnykh
While compiling OpenADK I discovered that there may be a case where UCLIBC_EXTRA_LDFLAGS contains `-fpie -pie`. Linker ignores `-shared` if `-pie` flag is passed after and produces an executable binary instead of shared object. This leads to linking failure because `ld-uClibc.so.1` becomes executable instead of shared object. `ld-uClibc.so.1` is used as one of the inputs when linking of libc.so.1 and linking proccess fails. To prevent this issue we need to pass extra `-shared` flag in `link.so` target command after all other flags to overwrite `-pie` effect. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-18features.h: Rework _DEFAULT_SOURCEPaul Cercueil
The (glibc) documentation for _DEFAULT_SOURCE states: The "default" definitions comprise those required by POSIX.1-2008 and ISO C99, as well as various definitions originally derived from BSD and System V. On glibc 2.19 and earlier, these defaults were approximately equivalent to explicitly defining the following: cc -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809 It also states that _BSD_SOURCE and _SVID_SOURCE are deprecated, and have the same effect as setting _DEFAULT_SOURCE. Therefore, when any of _BSD_SOURCE, _SVID_SOURCE or _DEFAULT_SOURCE is set, the three macros should be set, and POSIX 2008.09 compatibility should be enabled. Signed-off-by: Paul Cercueil <paul@crapouillou.net>
2024-02-18add newline at end of fileWaldemar Brodkorb
2024-02-10libc: Fix dns-related build issues.Dmitry Chestnykh
- The first observed issue is linking failure: ` /usr/bin/ld: libc/libc_so.a(encodeq.os): in function `__encode_question': encodeq.c:(.text+0x16): undefined reference to `__GI___dn_comp' /usr/bin/ld: libc/libc_so.a(dnslookup.os): in function `__dns_lookup': dnslookup.c:(.text+0x6fb): undefined reference to `__GI___dn_expand' /usr/bin/ld: dnslookup.c:(.text+0x7ab): undefined reference to `__hnbad' collect2: error: ld returned 1 exit status ` The root cause is that the resolv.c file contains some functions (dn_comp, dn_expand, __hnbad) under `#ifdef L_ns_name` and `#ifdef L_ns_comp` which wasn't defined, so we had undefined refs to such functions. - The second issue is misleading indentation inside `ns_name_pack`. ` libc/inet/resolv.c: In function '__ns_name_pack': libc/inet/resolv.c:3519:17: warning: this 'if' clause does not guard... 3519 | if (msg != NULL) ... ./include/errno.h:73:18: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' 73 | # define errno errno /* For #ifndef errno tests. */ | ^~~~~ libc/inet/resolv.c:3522:25: note: in expansion of macro 'errno' 3522 | errno = EMSGSIZE; ` Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-07ld.so: Add support of DT_RELR relocation format.Dmitry Chestnykh
Nowadays modern libcs like Glibc and musl currently support processing of RELATIVE relocations compressed with DT_RELR format. However I have noticed that uClibc-ng doesn't support this feature and if the source will be linked with `-Wl,-z,pack-relative-relos` (bfd) or `-Wl,--pack-dyn-relocs=relr` (lld) then ld.so cannot properly load the produced DSO. This patch is intended to fix this issue and adds applying of DT_RELR relative relocation. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-07Fix redefinition of _GNU_SOURCE.Dmitry Chestnykh
libc/misc/getloadavg/getloadavg.c:26: warning: "_GNU_SOURCE" redefined 26 | #define _GNU_SOURCE | In file included from <command-line>: ./include/libc-symbols.h:52: note: this is the location of the previous definition 52 | #define _GNU_SOURCE 1 Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-02-07sys/stat.h: Make fchmod() available if __USE_XOPEN2KPaul Cercueil
The fchmod() function is present in POSIX 2001.12. Signed-off-by: Paul Cercueil <paul@crapouillou.net>
2024-02-07sys/stat.h: Make S_ISSOCK() available if __USE_XOPEN2KPaul Cercueil
The S_ISSOCK() macro is present in POSIX 2001.12. Signed-off-by: Paul Cercueil <paul@crapouillou.net>
2024-01-18c6x: fix duplicate includeWaldemar Brodkorb
2023-12-22Fix -Wnon-literal-null-conversion clang warningMarius Melzer
Clang warns that the NULL character literal '\0' is used as a pointer value. Change this to 0 in order to avoid the warning.
2023-12-22Fix -Wgnu-designator clang warningsMarius Melzer
Clang warns about the use of old GNU-style designators. To avoid this, use the C99 designators instead.
2023-12-18bump version for 1.0.45 releasev1.0.45Waldemar Brodkorb
2023-12-12elf: support ELF binaries in noMMUGreg Ungerer
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>
2023-11-27linuxthreads: Avoid unused variable warningMarcus Haehnel
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.
2023-11-27getaddrinfo.c: Avoid misleading indentation warningMarcus Haehnel
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.
2023-11-17rlimit: fix 64-bit RLIM64_INFINITY macroPavel Kozlov
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>
2023-11-10fnmatch: fix possible access beyond of parameter stringMarcus Haehnel
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>
2023-11-10arc: remove read ahead in asm strcmp code for ARCHSPavel Kozlov
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>
2023-11-10arc: add acq/rel variants for atomic cmpxchg/xchgPavel Kozlov
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>
2023-11-10prlimit: add name redirection and fix incorrect parameters to syscallPavel Kozlov
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>
2023-11-09libpthread/nptl: make default stack size configurableBen Wolsieffer
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>
2023-11-02setjmp.h: Fix C++ build and avoid duplicate throw declarationMarcus Hähnel
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.
2023-11-02arm: elf-fdpic.h: avoid void pointer subtractionBen Wolsieffer
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>
2023-10-28Fix -Warray-parameter warning for __sigsetjmpPavel Kozlov
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>
2023-10-27setrlimit/getrlimit: fix prlimit64 syscall use for 32-bit CPUsPavel Kozlov
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>
2023-10-27depend on __UCLIBC_HAVE_STATX__Waldemar Brodkorb
Fixes compilation issues on mips64 n32.
2023-09-28riscv64: define __NR_riscv_flush_icache if not availableWaldemar Brodkorb