devel

devel@uclibc-ng.org

1 participants
1157 discussions

[PATCH] include/stdlib.h: only expose reallocarray() prototype when implementation is available
by Thomas Petazzoni 03 Apr '25

03 Apr '25

The reallocarray() primitive is only provided by the malloc-standard implementation: neither malloc nor malloc-simple provide it. This causes issues when building for example util-linux on noMMU platforms as: - noMMU platforms can't use malloc-standard, so either malloc or malloc-simple are used, which means reallocarray() is not implemented - util-linux detects the absence of reallocarray(), and provides its own implementation, but the prototype clashes with the prototype in uClibc's <stdlib.h> The combination of which causes the following build failure: In file included from lib/color-names.c:7: ./include/c.h:586:21: error: static declaration of ‘reallocarray’ follows non-static declaration 586 | static inline void *reallocarray(void *ptr, size_t nmemb, size_t size) | ^~~~~~~~~~~~ In file included from ./include/c.h:16: /home/thomas/projets/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/sysroot/usr/include/stdlib.h:898:14: note: previous declaration of ‘reallocarray’ with type ‘void *(void *, size_t, size_t)’ {aka ‘void *(void *, unsigned int, unsigned int)’} 898 | extern void *reallocarray (void *__ptr, size_t __m, size_t __n); | ^~~~~~~~~~~~ make[3]: *** [Makefile:12354: lib/libtcolors_la-color-names.lo] Error 1 To fix this, let's not expose the prototype of reallocarray() if we don't provide the implementation for it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> --- include/stdlib.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/stdlib.h b/include/stdlib.h index d4e0b75e7..448c5e336 100644 --- a/include/stdlib.h +++ b/include/stdlib.h @@ -986,9 +986,13 @@ extern int getpt (void); extern int getloadavg (double __loadavg[], int __nelem) __THROW __nonnull ((1)); +/* reallocarray() only provided by the malloc-standard implementation */ +#if defined(__MALLOC_STANDARD__) extern void *reallocarray (void *__ptr, size_t __m, size_t __n); #endif +#endif + #ifdef _LIBC extern int __drand48_iterate (unsigned short int xsubi[3], struct drand48_data *buffer) attribute_hidden; -- 2.48.1

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel