summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-03-19riscv64: add atomic.h, fixes tst-cond16, suggested by sorearWaldemar Brodkorb
2024-03-19riscv64: clone behaves like on aarch64, fixes tst-basic3, reported by sorearWaldemar Brodkorb
2024-03-19riscv64: sync with glibc clone.SWaldemar Brodkorb
2024-03-19riscv64: page size is 4096, reported by sorearWaldemar Brodkorb
2024-03-19riscv64: sync with glibc, fix all TLS errors in uClibc-ng-testWaldemar Brodkorb
2024-03-12add explicit_bzero from muslWaldemar Brodkorb
2024-03-12add reallocarray from muslWaldemar Brodkorb
2024-03-07libpthread/linuxthreads: add missing string.h include in condvar.cMarcus Haehnel
Quelches a compiler warning by that memset was implicitly declared.
2024-03-07libpthread: Remove no longer valid attribute_unusedMarcus Haehnel
The variable is used since 04a676f3c8d2443499f27612f69ee88e12089e61.
2024-03-04bump version for 1.0.46 releasev1.0.46Waldemar Brodkorb
2024-03-04update MAINTAINERSWaldemar Brodkorb
2024-03-04libm/w_j0f.c: Call correct ieee754 functionMarcus Haehnel
The j0f implementation should, like the other float implementations, call the __ieee754_y0 variant for doubles. A float variant is not declared and leads to a compile error on c99 builds.
2024-03-03x86: enable time64Waldemar Brodkorb
2024-03-03m68k: enable time64Waldemar Brodkorb
2024-03-03superh: enable time64Waldemar Brodkorb
2024-03-03microblaze: enable time64Waldemar Brodkorb
2024-03-03riscv32: add basic support for NPTLWaldemar Brodkorb
2024-03-03riscv32: add ldso support, enable time64.Waldemar Brodkorb
2024-03-03riscv32: decouple from riscv64Waldemar Brodkorb
2024-03-03remove symlinkWaldemar Brodkorb
2024-03-02Add time64 support to ARC.Dmitry Chestnykh
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
2024-03-01libc: Remove 32bit timespec structures everywhere.Dmitry Chestnykh
With time64 enabled we use statx() system call and the appropriate routines for results conversion. There is no need in `__ts32_struct` anymore. Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
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>