March 2025 - devel - example.com

fenv support in arch arm
by hacklife＠126.com 31 Mar '25

31 Mar '25

Hi guys， Hello, I want to ask why the uclibc-ng(test on version 1.0.39) does not support fenv(Symbol: UCLIBC_HAS_FENV) setting in arch arm, but it can be enabled in arch x86.

2 1

[PATCH] spawn.h: fix compiler warning about unused variable
by Marcus Haehnel 27 Mar '25

27 Mar '25

From: Frank Mehnert <frank.mehnert(a)kernkonzept.com> Avoid the warning by marking the unused parameter appropriately. Signed-off-by: Marcus Haehnel <marcus.haehnel(a)kernkonzept.com> --- include/spawn.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/spawn.h b/include/spawn.h index 3de375b41..cf01639c1 100644 --- a/include/spawn.h +++ b/include/spawn.h @@ -103,6 +103,7 @@ int posix_spawnattr_init (posix_spawnattr_t *__attr) static inline int posix_spawnattr_destroy (posix_spawnattr_t *__attr) { + (void)__attr; return 0; } -- 2.47.1

2 1

[RFC][PATCH] stdint.h: don't define __INT64_C / __UINT64_C if already defined
by Marcus Hähnel 27 Mar '25

27 Mar '25

Dear list, we came across a problem that might be very specific to our own setup and how we use the lib. We still wanted to share the patch if there is general interest. Recent Clang versions (Starting from 20) have the __INT64_C and __UINT64_C macros built-in. The compiler does not warn about this normally because <stdint.h> is a system header. In special cases where stdint.h may be included as normal header (which is the case for our system) it does warn however. Avoid re-defining if a definition already exists. The change would not impact users that use stdint.h exclusively as system header. Best regards, - Marcus -- +++++++++++++++++++ Register now for our workshop "Get to know L4Re in 3 days" on April 8-10. Learn to design and deploy secure system architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++++++++++++++++++ Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 1

[Patch] Use __ehdr_start as known zero link address symbol
by Marcus Hähnel 27 Mar '25

27 Mar '25

Hello devs, The _start symbol does not necessarily have to be on the first page of the application. But the __ehdr_start symbol is always at address zero for PIE binaries. So now we know how it works ;) Best regards, - Marcus -- +++++++++++++++++++ Register now for our workshop "Get to know L4Re in 3 days" on April 8-10. Learn to design and deploy secure system architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++++++++++++++++++ Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 1

Do not rely on unrelocated GOT entries
by Marcus Hähnel 27 Mar '25

27 Mar '25

Dear uclibc-ng devs, The LLVM linker seems to be quite clever. When resolving relocations, accesses to the GOT are potentially replaced by PC relative addressing to the requested symbol. This breaks the old method of calculating the load address by using an unrelocated GOT entry value. Instead, rely on __ehdr_start having a link address of zero.The LLVM linker seems to be quite clever. When resolving relocations, accesses to the GOT are potentially replaced by PC relative addressing to the requested symbol. This breaks the old method of calculating the load address by using an unrelocated GOT entry value. Instead, rely on __ehdr_start having a link address of zero. The patch is attached. Best regards, - Marcus -- +++++++++++++++++++ Register now for our workshop "Get to know L4Re in 3 days" on April 8-10. Learn to design and deploy secure system architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++++++++++++++++++ Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 1

use __ehdr_start to compute load address
by Marcus Hähnel 27 Mar '25

27 Mar '25

Dear List So far, uclibc relied on the informal behaviour of GNU ld to put the link address of the _DYNAMIC symbol in the first GOT entry. This does not work with LLVM lld which does not follow this convention. Consequently, glibc has abandoned its usage in favour of using __ehdr_start as magic symbol to infer the load address [1]. Note that this implies that the link time address of __ehdr_start is *always* 0! So far, this seems to be the case on all platforms. We implemented this change only for the platforms which we actively support and test at Kernkonzept (arm64, arm, i386, x86_64 and and riscv). The riscv64 dl-sysdep.h already used the method we converted the others to. For the other platforms we do not have the capacity to port this, but as long as noone wants to build them using lld this should not be an issue. Please feel free to test this on the relevant platforms before merging, to be sure it works as intended with the upstream version of the lib. Best regards, - Marcus [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28203 -- +++++++++++++++++++ Register now for our workshop "Get to know L4Re in 3 days" on April 8-10. Learn to design and deploy secure system architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++++++++++++++++++ Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth

2 2

test message, please ignore
by Waldemar Brodkorb 21 Mar '25

21 Mar '25

Hi, I upgraded the server to Debian 12. This is a test message. best regards Waldemar

1 0

100% CPU Issue in rsyslog's pthread_cond_wait() on m68k
by Jean-Michel Hautbois 13 Mar '25

13 Mar '25

Hi there, I have a quite complex issue, with uclibc-ng (master branch). Here is a summary. Tested with qemu (buildroot for q800) on the m68k architecture, rsyslog consumes 100% CPU during its pthread_cond_wait() calls. This is in [1] in the doIdleProcessing() function. Using glibc+m68k does not reveal this issue, and uclibc-ng on arm doesn't either. Strace output shows that the futex_time64() syscall is repeatedly returning EINVAL, indicating that the call is looping without proper blocking: # strace -f rsyslogd -dn <snip> [pid 110] write(1, "9139.913444393:main Q:Reg/w0 : "..., 859139.913444393:main Q:Reg/w0 : wti.c: main Q:Reg/w0: worker IDLE, waiting for work. ) = 85 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) Interestingly, a simple test program [2] works fine under similar conditions. I tried to dig and debug, but I can't find out what is the root cause and I suppose it can occur elsewhere, for another program... Hi there, I have a quite complex issue, with uclibc-ng. Here is a summary. Tested with qemu (buildroot for q800) on the m68k architecture, rsyslog consumes 100% CPU during its pthread_cond_wait() calls. This is in [1] in the doIdleProcessing() function. Using glibc+m68k does not reveal this issue, and uclibc-ng on arm doesn't either. Strace output shows that the futex_time64() syscall is repeatedly returning EINVAL, indicating that the call is looping without proper blocking: # strace -f rsyslogd -dn <snip> [pid 110] write(1, "9139.913444393:main Q:Reg/w0 : "..., 859139.913444393:main Q:Reg/w0 : wti.c: main Q:Reg/w0: worker IDLE, waiting for work. ) = 85 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) [pid 110] get_thread_area() = 0xc0b73970 [pid 110] get_thread_area() = 0xc0b73970 [pid 110] futex_time64(0x8009aee2, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL (Invalid argument) Interestingly, a simple test program [2] works fine under similar conditions. I tried to dig and debug, but I can't find out what is the root cause and I suppose it can occur elsewhere, for another program... Any help or suggestions would be appreciated! [1]: https://github.com/rsyslog/rsyslog/blob/master/runtime/wti.c#L362 [2]: https://www.geeksforgeeks.org/condition-wait-signal-multi-threading/ Thanks ! JM

2 2

[PATCH] ldso.h: factor out _dl_auxvt from ldso.h
by Marcus Haehnel 10 Mar '25

10 Mar '25

The _dl_auxvt is also used on non shared builds to access the values of the vector from getauxval. Putting the definitions in ldso.h leads to issues because that header also implements fcntl.h functionality making it incompatible with files that include that header directly. Factor out the _dl_auxvt related declarations to a new header dl-auxvt.h and include from ldso.h as well as include it directly from __uClibc_main.c to make the definitions available. Signed-off-by: Marcus Haehnel <marcus.haehnel(a)kernkonzept.com> --- ldso/include/dl-auxvt.h | 9 +++++++++ ldso/include/ldso.h | 6 +----- libc/misc/internals/__uClibc_main.c | 2 +- 3 files changed, 11 insertions(+), 6 deletions(-) create mode 100644 ldso/include/dl-auxvt.h diff --git a/ldso/include/dl-auxvt.h b/ldso/include/dl-auxvt.h new file mode 100644 index 000000000..29eda6eb3 --- /dev/null +++ b/ldso/include/dl-auxvt.h @@ -0,0 +1,9 @@ +#ifndef _DL_AUXVT_H +#define _DL_AUXVT_H + +#define AUX_MAX_AT_ID 40 +extern ElfW(auxv_t) _dl_auxvt[AUX_MAX_AT_ID]; /* Cache frequently accessed auxiliary vector entries */ +extern ElfW(auxv_t) *_dl_auxv_start; /* Start of the auxiliary vector */ + +#endif /* _DL_AUXVT_H */ + diff --git a/ldso/include/ldso.h b/ldso/include/ldso.h index a2c3ec040..061d8a536 100755 --- a/ldso/include/ldso.h +++ b/ldso/include/ldso.h @@ -34,7 +34,6 @@ #include <stdarg.h> #include <stddef.h> /* for ptrdiff_t */ #include <stdbool.h> -#if !defined(_FCNTL_H) #define _FCNTL_H /* We need this if arch has only new syscalls defined */ #ifndef AT_FDCWD @@ -191,11 +190,8 @@ extern void *_dl_get_ready_to_run(struct elf_resolve *tpnt, DL_LOADADDR_TYPE loa #include <dl-elf.h> #endif -#endif /* _FCNTL_H */ -#define AUX_MAX_AT_ID 40 -extern ElfW(auxv_t) _dl_auxvt[AUX_MAX_AT_ID]; /* Cache frequently accessed auxiliary vector entries */ -extern ElfW(auxv_t) *_dl_auxv_start; /* Start of the auxiliary vector */ +#include <dl-auxvt.h> void load_vdso(void *sys_info_ehdr, char **envp ); diff --git a/libc/misc/internals/__uClibc_main.c b/libc/misc/internals/__uClibc_main.c index 87f80d4f2..60695b6ed 100644 --- a/libc/misc/internals/__uClibc_main.c +++ b/libc/misc/internals/__uClibc_main.c @@ -84,7 +84,7 @@ static void fdpic_init_array_jump(void *addr) #ifndef SHARED void *__libc_stack_end = NULL; -#include "ldso.h" /* Needed for _dl_auxvt */ +#include "dl-auxvt.h" # ifdef __UCLIBC_HAS_SSP__ # include <dl-osinfo.h> -- 2.47.1

2 1

[PATCH 1/2] Make getauxval work with static linking
by Marcus Haehnel 07 Mar '25

07 Mar '25

From: Georg Kotheimer <georg.kotheimer(a)kernkonzept.com> While for dynamic linking the _dl_auxvt array is provided in dl-startup.c as part of the ldso, is was undefined for statically linked binaries. This resulted in a corresponding linker error if a statically linked program used getauxval. To provide _dl_auxvt also for statically linked binaries, a definition of _dl_auxvt is added to dl-support.c and initialized by _dl_aux_init(). Signed-off-by: Marcus Haehnel <marcus.haehnel(a)kernkonzept.com> --- libc/misc/elf/dl-support.c | 16 +++++++++++++--- libc/misc/internals/__uClibc_main.c | 22 ++++++---------------- 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/libc/misc/elf/dl-support.c b/libc/misc/elf/dl-support.c index 87cd1bb72..81c78fa55 100644 --- a/libc/misc/elf/dl-support.c +++ b/libc/misc/elf/dl-support.c @@ -12,6 +12,7 @@ */ #include <link.h> +#include <ldso.h> #include <elf.h> #if defined(USE_TLS) && USE_TLS #include <assert.h> @@ -31,17 +32,26 @@ ElfW(Phdr) *_dl_phdr; size_t _dl_phnum; size_t _dl_pagesize; +ElfW(auxv_t) _dl_auxvt[AUX_MAX_AT_ID]; + void internal_function _dl_aux_init (ElfW(auxv_t) *av); void internal_function _dl_aux_init (ElfW(auxv_t) *av) { + memset(_dl_auxvt, 0x00, sizeof(_dl_auxvt)); + for (; av->a_type != AT_NULL; av++) + { + if (av->a_type < AUX_MAX_AT_ID) + _dl_auxvt[av->a_type] = *av; + } + /* Get the program headers base address from the aux vect */ - _dl_phdr = (ElfW(Phdr) *) av[AT_PHDR].a_un.a_val; + _dl_phdr = (ElfW(Phdr) *) _dl_auxvt[AT_PHDR].a_un.a_val; /* Get the number of program headers from the aux vect */ - _dl_phnum = (size_t) av[AT_PHNUM].a_un.a_val; + _dl_phnum = (size_t) _dl_auxvt[AT_PHNUM].a_un.a_val; /* Get the pagesize from the aux vect */ - _dl_pagesize = (av[AT_PAGESZ].a_un.a_val) ? (size_t) av[AT_PAGESZ].a_un.a_val : PAGE_SIZE; + _dl_pagesize = (_dl_auxvt[AT_PAGESZ].a_un.a_val) ? (size_t) _dl_auxvt[AT_PAGESZ].a_un.a_val : PAGE_SIZE; } #if defined(USE_TLS) && USE_TLS diff --git a/libc/misc/internals/__uClibc_main.c b/libc/misc/internals/__uClibc_main.c index 64a9c8214..a84492248 100644 --- a/libc/misc/internals/__uClibc_main.c +++ b/libc/misc/internals/__uClibc_main.c @@ -43,7 +43,7 @@ /* Are we in a secure process environment or are we dealing * with setuid stuff? If we are dynamically linked, then we * already have _dl_secure, otherwise we need to re-examine - * auxvt[] below. + * _dl_auxvt[] below. */ int _pe_secure = 0; libc_hidden_data_def(_pe_secure) @@ -373,7 +373,6 @@ void __uClibc_main(int (*main)(int, char **, char **), int argc, { #ifndef SHARED unsigned long *aux_dat; - ElfW(auxv_t) auxvt[AT_EGID + 1]; #endif #ifdef __UCLIBC_HAS_THREADS_NATIVE__ @@ -399,23 +398,14 @@ void __uClibc_main(int (*main)(int, char **, char **), int argc, #ifndef SHARED /* Pull stuff from the ELF header when possible */ - memset(auxvt, 0x00, sizeof(auxvt)); aux_dat = (unsigned long*)__environ; while (*aux_dat) { aux_dat++; } aux_dat++; - while (*aux_dat) { - ElfW(auxv_t) *auxv_entry = (ElfW(auxv_t) *) aux_dat; - if (auxv_entry->a_type <= AT_EGID) { - memcpy(&(auxvt[auxv_entry->a_type]), auxv_entry, sizeof(ElfW(auxv_t))); - } - aux_dat += 2; - } /* Get the program headers (_dl_phdr) from the aux vector It will be used into __libc_setup_tls. */ - - _dl_aux_init (auxvt); + _dl_aux_init ((ElfW(auxv_t) *)aux_dat); #endif /* We need to initialize uClibc. If we are dynamically linked this @@ -431,10 +421,10 @@ void __uClibc_main(int (*main)(int, char **, char **), int argc, #ifndef SHARED /* Prevent starting SUID binaries where the stdin. stdout, and * stderr file descriptors are not already opened. */ - if ((auxvt[AT_UID].a_un.a_val == (size_t)-1 && __check_suid()) || - (auxvt[AT_UID].a_un.a_val != (size_t)-1 && - (auxvt[AT_UID].a_un.a_val != auxvt[AT_EUID].a_un.a_val || - auxvt[AT_GID].a_un.a_val != auxvt[AT_EGID].a_un.a_val))) + if ((_dl_auxvt[AT_UID].a_un.a_val == (size_t)-1 && __check_suid()) || + (_dl_auxvt[AT_UID].a_un.a_val != (size_t)-1 && + (_dl_auxvt[AT_UID].a_un.a_val != _dl_auxvt[AT_EUID].a_un.a_val || + _dl_auxvt[AT_GID].a_un.a_val != _dl_auxvt[AT_EGID].a_un.a_val))) #else if (_dl_secure) #endif -- 2.47.1

3 6