| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
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>
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
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>
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
- 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>
|
|
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
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>
|
|
Clang warns about null-pointer subtractions, which are undefined
behavior per the C standards. Replace the subtractions with
explicit casts to `uintptr_t`.
|
|
|
|
While they are not a problem per-se they cause issues with some tooling
(such as clang coverage) and are confusing to the reader.
|
|
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>
|
|
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
- 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>
|
|
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>
|
|
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>
|
|
The fchmod() function is present in POSIX 2001.12.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
|
|
The S_ISSOCK() macro is present in POSIX 2001.12.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
|
|
|
|
Clang warns that the NULL character literal '\0' is used as a pointer
value. Change this to 0 in order to avoid the warning.
|
|
Clang warns about the use of old GNU-style designators. To avoid this,
use the C99 designators instead.
|
|
|
|
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>
|
