devel

devel@uclibc-ng.org

3 participants
1149 discussions

Re: [uclibc-ng-devel] [PATCH 0/1] memmove/memcpy issue on MIPS

by Waldemar Brodkorb

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 >

5 years, 8 months

[PATCH] Fix header installation for recent 64-only arch

by Yann Sionneau

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

5 years, 8 months

riscv: add the MAP_UNINITIALIZED definition

by Christoph Hellwig

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

5 years, 8 months

[PATCH] riscv: clear a3/a4 in crt1

by Christoph Hellwig

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

5 years, 8 months

state of uClibc ARC soft-float support

by Vineet Gupta

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

5 years, 8 months

[PATCH] Fix compilation issue when libuargp is compiled without __UCLIBC_HAS_PROGRAM_INVOCATION_NAME__

by Yann Sionneau

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

5 years, 8 months

Re: [uclibc-ng-devel] [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined

by Yann Sionneau

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 >

5 years, 8 months

__LDSO_STANDALONE_SUPPORT__ applies to dlopen

by Luca Lindhorst

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

5 years, 9 months

-static-pie and FDPIC

by Christophe Lyon

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

5 years, 9 months

Re: [uclibc-ng-devel] [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined

by Waldemar Brodkorb

Hi, Petar Jovanovic wrote, > Hi Waldemar, > > test/string/tst-memmove.c > > fails without the change. 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/ best regards Waldemar

5 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel