devel

devel@uclibc-ng.org

1160 discussions

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

[PATCH] Fix compilation issue when libuargp is compiled without __UCLIBC_HAS_PROGRAM_INVOCATION_NAME__
by Yann Sionneau 21 Jun '19

21 Jun '19

This fixes the issue reported at https://github.com/wbx-github/uclibc-ng/issues/2 Signed-off-by: Yann Sionneau <yann(a)sionneau.net> --- libuargp/argp-parse.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libuargp/argp-parse.c b/libuargp/argp-parse.c index ecd5e7eb6..030bc4f9f 100644 --- a/libuargp/argp-parse.c +++ b/libuargp/argp-parse.c @@ -112,7 +112,7 @@ argp_default_parser (int key, char *arg, struct argp_state *state) break; case OPT_PROGNAME: /* Set the program name. */ -#if defined _LIBC || HAVE_DECL_PROGRAM_INVOCATION_NAME +#if defined _LIBC && defined(__UCLIBC_HAS_PROGRAM_INVOCATION_NAME__) program_invocation_name = arg; #endif /* [Note that some systems only have PROGRAM_INVOCATION_SHORT_NAME (aka @@ -126,7 +126,7 @@ argp_default_parser (int key, char *arg, struct argp_state *state) else state->name = arg; -#if defined _LIBC || HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME +#if defined _LIBC && defined(__UCLIBC_HAS_PROGRAM_INVOCATION_NAME__) program_invocation_short_name = state->name; #endif -- 2.17.1

2 1

Re: [uclibc-ng-devel] [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined
by Yann Sionneau 20 Jun '19

20 Jun '19

Is there a buildroot and qemu supported board/cpu that can reproduce the issue? mips32r1 is not in the "qemu board" supported by buildroot: https://github.com/buildroot/buildroot/tree/master/board/qemu On 6/20/19 5:13 PM, Petar Jovanovic wrote: > Ping. > > -----Original Message----- > From: Petar Jovanovic [mailto:petar.jovanovic@rt-rk.com] > Sent: Tuesday, June 4, 2019 11:58 AM > To: 'Waldemar Brodkorb' <mail(a)waldemar-brodkorb.de> > Cc: 'Petar Jovanovic' <mips32r2(a)gmail.com>; 'devel(a)uclibc-ng.org' <devel(a)uclibc-ng.org>; 'Yann Sionneau' <ysionneau(a)kalray.eu>; 'Konstantin Vasin' <kvasin(a)dlink.ru>; 'Volodymyr Boyko' <boyko.cxx(a)gmail.com> > Subject: RE: [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined > > Ping. > > -----Original Message----- > From: Petar Jovanovic [mailto:petar.jovanovic@rt-rk.com] > Sent: Monday, May 20, 2019 4:21 PM > To: 'Waldemar Brodkorb' <mail(a)waldemar-brodkorb.de> > Cc: 'Petar Jovanovic' <mips32r2(a)gmail.com>; 'devel(a)uclibc-ng.org' <devel(a)uclibc-ng.org>; 'Yann Sionneau' <ysionneau(a)kalray.eu>; 'Konstantin Vasin' <kvasin(a)dlink.ru>; 'Volodymyr Boyko' <boyko.cxx(a)gmail.com> > Subject: RE: [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined > >> On which hardware or f.e. in Qemu? >> I can't see the failure for 1.0.31 in the MIPS configurations: >> https://downloads.uclibc-ng.org/reports/1.0.31/ > It fails on multiple boards. > The bug was first discovered on mips32r1 Broadcom board, but it can also be reproduced on other platforms (e.g. Cavium Octeon II, etc). > > Regards, > Petar >

1 0

__LDSO_STANDALONE_SUPPORT__ applies to dlopen
by Luca Lindhorst 07 Jun '19

07 Jun '19

Hello, I noticed that the define "__LDSO_STANDALONE_SUPPORT__" does not just prevents you from calling a binary via ld e.g. '/lib/ld-uClibc.so my-binary', but also prevents programs from loading a binary via dlopen. Is this intended? If so the name is at least confusing. Greetings Luca Lindhorst -- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten. Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen auf Grundlage dieser Aussagen treffen. Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis Registergericht: Amtsgericht Wuppertal, HRB 6377 Infos zum Datenschutz: http://www.wut.de/datenschutz Tel. +49-202/2680-0, Fax +49-202/2680-265, http://www.wut.de

3 9

-static-pie and FDPIC
by Christophe Lyon 27 May '19

27 May '19

Hi, My recent attempt at submitting the GCC patch series to add FDPIC support for arm triggered a discussion about -static-pie support [1], which continued on IRC. The patch currently supports -static but the resulting binary still needs the dynamic linker to prepare the parameters for __self_reloc, and there are arguments that a static binary should not have a PT_INTERP field. At present, musl supports -static-pie for sh+FDPIC only. I think other uclibc-ng targets with FDPIC (frv, bfin) do not support -static, but I'm not sure how to build such toolchains, nor if they are still supported. It seems I have several options: (a) add support for static-pie to uclibc-ng. This means creating a new rcrt1.o or similar, which would embed parts of the dynamic linker into static-pie executables. I'm not sure how big a task this is? (b) add support for FDPIC on arm to musl, which I'm not familiar with (c) declare -static not supported on arm-FDPIC (d) gather consensus that -static with pt_interp is ok (my preference, since that's what the current patches do :-) So, my questions are: - does uclibc-ng support -static on some FDPIC targets? which ones? - how much work would option (a) mean? - are uclibc-ng people opposed to option (d)? Thanks, Christophe [1] https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00820.html

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel