- devel - example.com

xtensa failures in buildroot
by Waldemar Brodkorb 12 Oct '19

12 Oct '19

Hi Max, is attached patch okay for you? Fixes the recent br errors for uClibc-ng. best regards Waldemar

2 1

[PATCH] or1k: Fix compiling with PIC and latest binutils use PLT for __syscall_error
by Stafford Horne 09 Oct '19

09 Oct '19

This symbol was causing a build failure with the new toolchain. It looks like it has always been wrong. The main issue was checking for PIC rather than __PIC__. Remove all PSEUDO_* macros and ther SYSCALL_ERROR_NAME macro as they are not needed by uclibc-ng, they are used in glibc for building up syscalls there, but not here. Fixes error: /opt/shorne/software/or1k-linux/bin/../lib/gcc/or1k-linux/9.0.1/../../../../or1k-linux/bin/ld: libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol __syscall_error /opt/shorne/software/or1k-linux/bin/../lib/gcc/or1k-linux/9.0.1/../../../../or1k-linux/bin/ld: final link failed: bad value Signed-off-by: Stafford Horne <shorne(a)gmail.com> --- libc/sysdeps/linux/or1k/or1k_clone.S | 8 +++++-- libc/sysdeps/linux/or1k/sysdep.h | 32 ---------------------------- 2 files changed, 6 insertions(+), 34 deletions(-) diff --git a/libc/sysdeps/linux/or1k/or1k_clone.S b/libc/sysdeps/linux/or1k/or1k_clone.S index a2c16ac9e..2de873a02 100644 --- a/libc/sysdeps/linux/or1k/or1k_clone.S +++ b/libc/sysdeps/linux/or1k/or1k_clone.S @@ -71,7 +71,11 @@ L(oldpid): l.ori r3, r11, 0 L(error): - l.j SYSCALL_ERROR_NAME +#ifdef __PIC__ + l.j plt(__syscall_error) +#else + l.j __syscall_error +#endif l.ori r3,r11,0 -PSEUDO_END (__or1k_clone) +END (__or1k_clone) diff --git a/libc/sysdeps/linux/or1k/sysdep.h b/libc/sysdeps/linux/or1k/sysdep.h index 4dba3f2a0..782981c55 100644 --- a/libc/sysdeps/linux/or1k/sysdep.h +++ b/libc/sysdeps/linux/or1k/sysdep.h @@ -43,38 +43,6 @@ License along with the GNU C Library; if not, see l.sys 1; \ l.nop -#define PSEUDO(name, syscall_name, args) \ - ENTRY (name); \ - DO_CALL(syscall_name); \ - /* if -4096 < ret < 0 holds, it's an error */ \ - l.sfgeui r11, 0xf001; \ - l.bf L(pseudo_end); \ - l.nop - -#define PSEUDO_NOERRNO(name, syscall_name, args) \ - ENTRY (name); \ - DO_CALL(syscall_name) - -#define PSEUDO_END(name) \ -L(pseudo_end): \ - l.j SYSCALL_ERROR_NAME; \ - l.ori r3,r11,0; \ - END (name) - -#define PSEUDO_END_NOERRNO(name) \ - END (name) - -#ifndef PIC -/* For static code, on error jump to __syscall_error directly. */ -# define SYSCALL_ERROR_NAME __syscall_error -#elif NOT_IN_libc -/* Use the internal name for libc/libpthread shared objects. */ -# define SYSCALL_ERROR_NAME __GI___syscall_error -#else -/* Otherwise, on error do a full PLT jump. */ -# define SYSCALL_ERROR_NAME plt(__syscall_error) -#endif - /* Make use of .size directive. */ #define ASM_SIZE_DIRECTIVE(name) .size name,.-name; -- 2.21.0

3 3

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