- devel - example.com

bug: stdio funcs, thread cancellation with futex hold
by Yann Sionneau 27 Sep '19

27 Sep '19

Hello, I would like to know if there is consensus on the fact that this program hanging on a deadlock is a uClibc-ng bug: https://pastebin.com/11qLsTW5 I've asked people to try this on several arch/libc combination, it works well (no hang) on: * x86_64/glibc * x86_64/musl * armv7l/musl Also, I've run the puts.c test (linked above) on 3 archs with uClibc-ng, it fails (hangs) on: * or1k/uClibc-ng * mips32r6/uClibc-ng * k1c/uClibc-ng (port not completely published yet) See failure logs + strace -f of what happens when hanging: https://mypads.framapad.org/mypads/?/mypads/group/uclibc-ng-10be37ap/pad/vi… My understanding of the issue is that: puts, and possibly other libc functions, are taking a lock ( https://elixir.bootlin.com/uclibc-ng/latest/source/libc/stdio/puts.c#L17 ) and end up calling write() which is a cancellation point. ( https://elixir.bootlin.com/uclibc-ng/latest/source/libc/stdio/_stdio.h#L150 ) So, if a thread is canceled, is asynchronous mode (which is the default one), and the cancelation is triggered by the write() inside the puts(), then the thread will unwind and exit without unlocking the puts lock. Then, any other thread calling puts() will hang indefinetely (and hang other threads if it hangs with locks held...). My understanding of what can be done to fix this issue: 1/ Either make puts a non cancelation point (see man 7 pthreads, puts is not listed in mandatory cancelation point, only in "may"). For instance it is not a cancelation point in glibc. 2/ Or keep puts as a cancelation point and fix the puts code so that it releases the lock upon cancelation (using pthread_cleanup_push/pop for instance) In case people think this is indeed a bug, here are examples of code fixes that I have in mind, please don't hesitate to comment or/and propose something else: 1/ https://pastebin.com/ePsWJzdi 2/ https://pastebin.com/5EA4RedS One problem of those fixes is that we need to identify all libc functions that take a lock and call a cancellable function and apply such kind of fixes... This is not easy and a bit painful. Thanks! Regards, -- Yann Sionneau

2 1

[PATCH] malloc: Add missing locks for some paths (valloc/memalign/posix_memalign)
by Kjetil Oftedal 25 Sep '19

25 Sep '19

The internal heap structures were not protected properly in memalign(). If multiple threads were concurrently allocating memory and one of them were requesting aligned memory via valloc,memalign or posix_memalign the internal heap data structures could be corrupted. Signed-off-by: Kjetil Oftedal <oftedal(a)gmail.com> --- libc/stdlib/malloc/memalign.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libc/stdlib/malloc/memalign.c b/libc/stdlib/malloc/memalign.c index 74d5dbd..0d3de67 100644 --- a/libc/stdlib/malloc/memalign.c +++ b/libc/stdlib/malloc/memalign.c @@ -77,7 +77,9 @@ memalign (size_t alignment, size_t size) init_size = addr - tot_addr; } + __heap_lock (&__malloc_heap_lock); __heap_free (heap, base, init_size); + __heap_unlock (&__malloc_heap_lock); /* Remember that we've freed the initial part of MEM. */ base += init_size; @@ -85,9 +87,11 @@ memalign (size_t alignment, size_t size) /* Return the end part of MEM to the heap, unless it's too small. */ end_addr = addr + size; - if (end_addr + MALLOC_REALLOC_MIN_FREE_SIZE < tot_end_addr) + if (end_addr + MALLOC_REALLOC_MIN_FREE_SIZE < tot_end_addr) { + __heap_lock (&__malloc_heap_lock); __heap_free (heap, (void *)end_addr, tot_end_addr - end_addr); - else + __heap_unlock (&__malloc_heap_lock); + } else /* We didn't free the end, so include it in the size. */ end_addr = tot_end_addr; -- 1.7.9.5

2 2

Potential bug with feof, fgetc, and ferror
by Rosen Penev 29 Aug '19

29 Aug '19

Reference: https://lists.gnu.org/archive/html/bug-ddrescue/2019-05/msg00000.html https://lists.gnu.org/archive/html/bug-ddrescue/2019-05/msg00001.html Basically, these functions are defined as macros and not being included in std. If compiling with GCC libstdcpp, it works because internally, the header #undefs these functions. This is not the case with uClibc++(or maybe some other libc++).

1 0

[ork1] issue with Binutils 2.32 and gcc 9.x
by Romain Naour 26 Aug '19

26 Aug '19

Hi Waldemar, I discovered an issue with uClibc and binutils 2.32 and gcc 9.1 or 9.2. LD libuClibc-1.0.31.so /opt/openrisc--uclibc--bleeding-edge-1/lib/gcc/or1k-buildroot-linux-uclibc/9.2.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol __syscall_error See: https://gitlab.com/kubu93/toolchains-builder/-/jobs/270854456 This error message come from a new check in binutils 2.32.x: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f2c… With binutils 2.30.x and 2.31.x, I have another assembler error: Error: junk at end of line `l.movhi r17,gotoffha(.LC0)' ork1 support was added to gcc 9.x and enabled into Buildroot recently. https://git.buildroot.net/buildroot/commit/?id=da70a55a1955ff673e0110bacb3d… I remember doing a test with qemu_or1k_defconfig before gcc 9.1 was released but I don't remember if it was with musl or uClibc-ng... It should be with uClibc-ng but I didn't trigged such error. Thoughts ? Best regards, Romain

3 7

Using thread local storage on aarch64
by Christoph Mammitzsch 30 Jul '19

30 Jul '19

Hi, I was trying to compile a buildroot-2019.02.4 system for an aarch64 platform using gcc 8.3.0 and uClibc-ng-1.0.31. Everything seemed to boot fine, but when I added the ntpd daemon, the daemon kept segfaulting. Some debugging showed, that the segfault happened inside the res_init function, so i made the following test program: ----test_res_init.c---- #include <resolv.h> void main(void) { res_init(); } ----------------------- This program always segfaults as soon as res_init tries to access the _res structure. Some more debugging revealed, that there seems to be a general problem with accessing thread local storage from a dynamicly linked library, so I wrote the following test code: ----test_lib.c---- #include <stdio.h> int ii; __thread int *iip = &ii; void print_ptrs(void) { printf("print_ptrs:\n"); printf("&iip = %p\n", &iip); printf("&ii = %p\n", &ii); printf("iip = %p\n", iip); } ----test_tls.c---- #include <stdio.h> void print_ptrs(void); extern int ii; extern __thread int *iip; void main(void) { printf("main:\n"); printf("&iip = %p\n", &iip); printf("&ii = %p\n", &ii); printf("iip = %p\n", iip); print_ptrs(); } ------------------ When compiling the source linke this: # aarch64-linux-gcc -g -fPIC -c -o test_lib.o test_lib.c # aarch64-linux-gcc -shared -o test_lib.so test_lib.o # aarch64-linux-gcc -g test_tls.c test_lib.so -o test_tls the result looks like this: ------------------------------- # LD_LIBRARY_PATH=/root /root/test_tls main: &iip = 0x7fa0d756d0 &ii = 0x411048 iip = 0x411048 print_ptrs: &iip = 0xff41ac4d90 &ii = 0x411048 [ 7654.009770] test_tls[1942]: unhandled level 0 translation fault (11) at 0xff41ac4d90, esr 0x92000004 [ 7654.018844] pgd = ffffffc07d48c000 [ 7654.027775] [ff41ac4d90] *pgd=0000000000000000 [ 7654.036007] , *pud=0000000000000000 [ 7654.039488] [ 7654.040951] [ 7654.042441] CPU: 2 PID: 1942 Comm: test_tls Not tainted 4.9.0-g196f33d0-dirty #6 [ 7654.049820] Hardware name: xlnx,zynqmp (DT) [ 7654.053981] task: ffffffc05e71ad00 task.stack: ffffffc05d9d4000 [ 7654.059884] PC is at 0x7fa0d4f8f4 [ 7654.063186] LR is at 0x7fa0d4f8ec [ 7654.066478] pc : [<0000007fa0d4f8f4>] lr : [<0000007fa0d4f8ec>] pstate: 60000000 [ 7654.073864] sp : 0000007fe5405170 [ 7654.077148] x29: 0000007fe5405170 x28: 0000000000000000 [ 7654.082442] x27: 0000000000000000 x26: 0000000000000000 [ 7654.087736] x25: 0000000000000000 x24: 0000000000000000 [ 7654.093031] x23: 0000000000000000 x22: 0000000000000000 [ 7654.098326] x21: 0000000000400740 x20: 0000000000000000 [ 7654.103620] x19: 0000000000000000 x18: 0000000000000000 [ 7654.108915] x17: 0000007fa0c8f698 x16: 0000007fa0d60000 [ 7654.114210] x15: 0000000000000001 x14: 0000000000000000 [ 7654.119505] x13: 0000007fa0d77a18 x12: 0000000000000018 [ 7654.124800] x11: 0000000000000001 x10: 0000007fa0d4f517 [ 7654.130095] x9 : 0000007fa0d77a08 x8 : 0000000000000040 [ 7654.135389] x7 : 000000000000000a x6 : 000000000000000a [ 7654.140684] x5 : 0000007fa0d36b6f x4 : 0000007fa0d4f951 [ 7654.145979] x3 : 0000000000000000 x2 : 36bc912578986b49 [ 7654.151274] x1 : 0000007fa0d756c0 x0 : 000000ff41ac4d90 [ 7654.156568] Segmentation fault ------------------------------- Note that the program shows two different addresses for &iip with the latter pointing outside the normal memory map. However the test_tls program works as expected, if you set the LD_BIND_NOW environment variable: ------------------------------- # LD_BIND_NOW=1 LD_LIBRARY_PATH=/root /root/test_tls main: &iip = 0x7f99b606d0 &ii = 0x411048 iip = 0x411048 print_ptrs: &iip = 0x7f99b606d0 &ii = 0x411048 iip = 0x411048 ------------------------------- Unfortunately this trick does not seem to work for either the test_res_init program or the ntpd. Regards, Christoph Mammitzsch

1 0

Re: [uclibc-ng-devel] [PATCH 0/1] memmove/memcpy issue on MIPS
by Waldemar Brodkorb 05 Jul '19

05 Jul '19

Hi, patch applied and pushed, Waldemar Petar Jovanovic wrote, > Hi All, > > The previous patch to fix generic memmove() was incorrect even though it > fixed issues with the tests. The comments in the memmove() function and > different failing test cases misled me to believe the call to memcopy() > was wrongly conditioned by __ARCH_HAS_BWD_MEMCPY__. It was not. > > This generic memmove implementation assumes that memcpy does forward > copying and that no issues could be seen in this case. However, at least > MIPS arch has an optimized memcpy that uses prefetching and that > implementation does not work correctly for overlapping regions. > > So, my suggestions is that for now we skip memcpy() calls for MIPS, and > if more arches in future come across this, we can unify it (same as it > was done for __ARCH_HAS_BWD_MEMCPY__). > > Sorry for not fixing this correctly in the first patch already. > > Thanks. > > Regards, > Petar > > Petar Jovanovic (1): > mips: avoid calling memcpy() from memmove() for MIPS arch > > libc/string/generic/memmove.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > -- > 2.17.1 >

2 1

[PATCH] Fix header installation for recent 64-only arch
by Yann Sionneau 05 Jul '19

05 Jul '19

Summary: Recent arch do not support Legacy. Thus they don't define ARCH_HAS_DEPRECATED_SYSCALLS But this led to per-arch headers not being installed and common-generic ones taking precedence. So it was impossible to declare arch-specific statfs.h for instance, to force 64-bit mode only. This was leading to the following situation to happen: 1/ an application compiles (say without -D_FILE_OFFSET_BITS set) it therefore uses struct statfs from libc/sysdeps/linux/common-generic/bits/statfs.h where f_type and f_bsize fields are U32: https://elixir.bootlin.com/uclibc-ng/latest/source/libc/sysdeps/linux/commo… 2/ application calls "statfs" 3/ uClibc issues "statfs64" syscall (because __NR_statfs64 is defined and __NR_statfs is undefined): https://elixir.bootlin.com/uclibc-ng/latest/source/libc/sysdeps/linux/commo… 4/ if Linux kernel port is not defining CONFIG_COMPAT, it calls do_statfs_native https://elixir.bootlin.com/linux/latest/source/fs/statfs.c#L195 5/ it does copy_to_user of the size of struct statfs defined in the kernel source tree: https://elixir.bootlin.com/linux/latest/source/fs/statfs.c#L161 6/ Generic struct statfs in the kernel is defined like this: https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/sta… f_type and f_bsize fields are long (64 bits) for 64-bit archs. 7/ memory corruption occurs because of this mismatch Solution: Allow to not define __ARCH_HAS_DEPRECATED_SYSCALLS__ *and* declare its own arch-specific statfs.h header, matching the kernel one. (for instance with f_type and f_bsize defined as long) Does this change break other archs? This change allows headers in libc/sysdeps/linux/<ARCH>/bits/ to override ones in libc/sysdeps/linux/common-generic/bits/ The only arch which does not define __ARCH_HAS_DEPRECATED_SYSCALLS__ *and* has a header in libc/sysdeps/linux/<ARCH>/bits/ which can conflict with one in libc/sysdeps/linux/common-generic/bits/ is c6x. The file that can override is ../libc/sysdeps/linux/c6x/bits/kernel_stat.h This, btw, means that, today, this file is there and is not used (during compilation, GNU Make overrides the rule): Makefile.in:152: warning: overriding recipe for target `include/bits/kernel_stat.h' Makefile.in:148: warning: ignoring old recipe for target `include/bits/kernel_stat.h' I was not able to compile uClibc with the only binary toolchain I found for c6x arch (gcc-4.5.1 from code sourcery: https://sourcery.mentor.com/GNUToolchain/release1882) However, I can tell that c6x's kernel_stat.h only defines two structs: kernel_stat and kernel_stat64: https://elixir.bootlin.com/uclibc-ng/latest/source/libc/sysdeps/linux/c6x/b… And I can also tell that those structs are only used when using xstat conversion functions (__xstat32_conv / xstat_conv) which are only used and present in the __ARCH_HAS_DEPRECATED_SYSCALLS__ == y case. However, c6x does not define __ARCH_HAS_DEPRECATED_SYSCALLS__ So I think I can say that this change does not affect c6x nor other archs. --- Makefile.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile.in b/Makefile.in index 1754040..16ee9ee 100644 --- a/Makefile.in +++ b/Makefile.in @@ -144,14 +144,14 @@ $(top_builddir)include/dl-osinfo.h $(top_builddir)include/not-cancel.h: $(ALL_HEADERS_BITS_COMMON): $(do_ln) $(call rel_srcdir)libc/sysdeps/linux/common/bits/$(@F) $@ -$(ALL_HEADERS_BITS_ARCH): - $(do_ln) $(call rel_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)/bits/$(@F) $@ - ifneq ($(ARCH_HAS_DEPRECATED_SYSCALLS),y) $(ALL_HEADERS_BITS_COMMON_NO_LEGACY): $(do_ln) $(call rel_srcdir)libc/sysdeps/linux/common-generic/bits/$(@F) $@ endif +$(ALL_HEADERS_BITS_ARCH): + $(do_ln) $(call rel_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)/bits/$(@F) $@ + ifneq ($(TARGET_SUBARCH),) $(ALL_HEADERS_BITS_SUBARCH): $(do_ln) $(call rel_srcdir)libc/sysdeps/linux/$(TARGET_ARCH)/bits/$(TARGET_SUBARCH)/$(@F) $@ -- 1.8.3.1

2 1

riscv: add the MAP_UNINITIALIZED definition
by Christoph Hellwig 05 Jul '19

05 Jul '19

From: Christoph Hellwig <hch(a)lst.de> This avoids a nommu build failure. Signed-off-by: Christoph Hellwig <hch(a)lst.de> --- libc/sysdeps/linux/riscv64/bits/mman.h | 1 + 1 file changed, 1 insertion(+) diff --git a/libc/sysdeps/linux/riscv64/bits/mman.h b/libc/sysdeps/linux/riscv64/bits/mman.h index 316f87d99..fa6f8e6a0 100644 --- a/libc/sysdeps/linux/riscv64/bits/mman.h +++ b/libc/sysdeps/linux/riscv64/bits/mman.h @@ -31,6 +31,7 @@ # define MAP_HUGETLB 0x40000 /* Create huge page mapping. */ # define MAP_SYNC 0x80000 /* Perform synchronous page faults for the mapping. */ +# define MAP_UNINITIALIZED 0x4000000 /* For anonymous mmap, memory could - be uninitialized. */ #endif /* Include generic Linux declarations. */ -- 2.20.1

2 1

[PATCH] riscv: clear a3/a4 in crt1
by Christoph Hellwig 24 Jun '19

24 Jun '19

From: Christoph Hellwig <hch(a)lst.de> We don't support shared libraries and thus _init/_fini. But loading nommu binaries blows they aren't cleared, so do that. Signed-off-by: Christoph Hellwig <hch(a)lst.de> --- libc/sysdeps/linux/riscv64/crt1.S | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/libc/sysdeps/linux/riscv64/crt1.S b/libc/sysdeps/linux/riscv64/crt1.S index 872e0b12e..1e8403d26 100644 --- a/libc/sysdeps/linux/riscv64/crt1.S +++ b/libc/sysdeps/linux/riscv64/crt1.S @@ -52,6 +52,11 @@ _start: la a0, main REG_L a1, 0(sp) /* argc. */ addi a2, sp, SZREG /* argv. */ + /* + * No support fo app_init/app_fini as we don't support shared libraries. + */ + mv a3, zero + mv a4, zero andi sp, sp, ALMASK /* Align stack. */ mv a6, sp /* stack_end. */ -- 2.20.1

1 0

state of uClibc ARC soft-float support
by Vineet Gupta 24 Jun '19

24 Jun '19

Hi Waldemar, After test-suite commit 9f079b6353 "(disable complex math)" the math tests build and I see lot of failures (for the default soft float builds) .... test-float-finiteFAIL test-float-finite got 1 expected 0 .... test-floatFAIL test-float got 1 expected 0 .... test-idoubleFAIL test-idouble got 1 expected 0 .... test-ifloatFAIL test-ifloat got 1 expected 0 .... test-matherrFAIL test-matherr got 1 expected 0 .... test-nan-overflowFAIL test-nan-overflow got 1 expected 0 .... test-nan-payloadFAIL test-nan-payload got 1 expected 0 Interestingly in ARC glibc port, soft float builds, all flaot tests pass (so atleast gcc/libgcc foo seem to be fine I think). I noticed a few things: 1. ulps for ARC was removed from test-sute last year - so I copied over the version from ARC glibc port [1] 2. I suppose these don't depend on UCLIBC_HAS_FENV. Anyhow It seems uClibc __UCLIBC_HAS_FENV__ implies hardware float as it expects all FE_* exceptions/rounding modes to be defined in ARCH specific file. Anyhow I tried creating an ARC specific fenv to support soft float with no exceptions and only single rounding mode but that doesn't seem to help. Any idea what I'm missing or if it is worth pursuing at all. Thx, -Vineet [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-January/005347.html

3 3