devel June 2019

devel@uclibc-ng.org

8 participants
7 discussions

[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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel June 2019