devel May 2019

devel@uclibc-ng.org

9 participants
10 discussions

__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

Re: [uclibc-ng-devel] [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined
by Waldemar Brodkorb 17 May '19

17 May '19

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

2 1

[PATCH] preadv/pwritev: fix offset argument type
by Max Filippov 15 May '19

15 May '19

preadv/pwritev don't provide separate version for 64-bit wide off_t, and default to 32-bit wide off_t, which results in a mismatch between declaration and definition for user programs built with -D_FILE_OFFSET_BITS=64. Make offset argument of both functions __off64_t. This fixes test misc/tst-preadvwritev on xtensa. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- include/sys/uio.h | 4 ++-- libc/sysdeps/linux/common/preadv.c | 2 +- libc/sysdeps/linux/common/pwritev.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/sys/uio.h b/include/sys/uio.h index aa766f9b1187..330426fec492 100644 --- a/include/sys/uio.h +++ b/include/sys/uio.h @@ -59,7 +59,7 @@ extern ssize_t writev (int __fd, const struct iovec *__iovec, int __count); This function is a cancellation point and therefore not marked with __THROW. */ extern ssize_t preadv (int __fd, const struct iovec *__iovec, int __count, - off_t __offset) __wur; + __off64_t __offset) __wur; /* Write data pointed by the buffers described by IOVEC, which is a vector of COUNT 'struct iovec's, to file descriptor FD at the given @@ -71,7 +71,7 @@ extern ssize_t preadv (int __fd, const struct iovec *__iovec, int __count, This function is a cancellation point and therefore not marked with __THROW. */ extern ssize_t pwritev (int __fd, const struct iovec *__iovec, int __count, - off_t __offset) __wur; + __off64_t __offset) __wur; #endif /* Use misc. */ __END_DECLS diff --git a/libc/sysdeps/linux/common/preadv.c b/libc/sysdeps/linux/common/preadv.c index fd9dde4b999c..6a07d5df87e0 100644 --- a/libc/sysdeps/linux/common/preadv.c +++ b/libc/sysdeps/linux/common/preadv.c @@ -21,7 +21,7 @@ #ifdef __NR_preadv ssize_t -preadv (int fd, const struct iovec *vector, int count, off_t offset) +preadv (int fd, const struct iovec *vector, int count, __off64_t offset) { unsigned long pos_l, pos_h; diff --git a/libc/sysdeps/linux/common/pwritev.c b/libc/sysdeps/linux/common/pwritev.c index bef5bcf69b46..f07c40e6de3c 100644 --- a/libc/sysdeps/linux/common/pwritev.c +++ b/libc/sysdeps/linux/common/pwritev.c @@ -21,7 +21,7 @@ #ifdef __NR_pwritev ssize_t -pwritev (int fd, const struct iovec *vector, int count, off_t offset) +pwritev (int fd, const struct iovec *vector, int count, __off64_t offset) { unsigned long pos_l, pos_h; -- 2.11.0

3 4

Re: [uclibc-ng-devel] [PATCH] mips: fix memmove() call when __ARCH_HAS_BWD_MEMCPY__ is not defined
by Waldemar Brodkorb 13 May '19

13 May '19

Hi, do you have some test case showing the behaviour? best regards Waldemar Petar Jovanovic wrote, > Can somebody take a look at this and apply it? > > Thank you. > > Regards, > Petar > > On Mon, May 6, 2019 at 3:29 PM Petar Jovanovic > <petar.jovanovic(a)rt-rk.com> wrote: > > > > When arch (such as MIPS) does not define __ARCH_HAS_BWD_MEMCPY__, memmove() > > calls memcpy() which is wrong for overlapping regions. > > > > Signed-off-by: Petar Jovanovic <petar.jovanovic(a)rt-rk.com> > > --- > > libc/string/generic/memmove.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/libc/string/generic/memmove.c b/libc/string/generic/memmove.c > > index bf78c4778..1ac018013 100644 > > --- a/libc/string/generic/memmove.c > > +++ b/libc/string/generic/memmove.c > > @@ -23,7 +23,7 @@ > > #include "memcopy.h" > > #include "pagecopy.h" > > > > -#ifdef __ARCH_HAS_BWD_MEMCPY__ > > +#ifndef __ARCH_HAS_BWD_MEMCPY__ > > /* generic-opt memmove assumes memcpy does forward copying! */ > > #include "_memcpy_fwd.c" > > #endif > > @@ -224,8 +224,8 @@ void *memmove (void *dest, const void *src, size_t len) > > Reduces the working set. */ > > if (dstp - srcp >= len) /* *Unsigned* compare! */ > > { > > -#ifndef __ARCH_HAS_BWD_MEMCPY__ > > - /* Backward memcpy implementation cannot be used */ > > +#ifdef __ARCH_HAS_BWD_MEMCPY__ > > + /* Backward memcpy implementation can be used */ > > memcpy(dest, src, len); > > #else > > /* Copy from the beginning to the end. */ > > -- > > 2.17.1 > > >

1 0

[PATCH v2] docs/defines.txt: clarify LFS-related macros
by Max Filippov 10 May '19

10 May '19

Add description for _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, _FILE_OFFSET_BITS and __USE_LARGEFILE, __USE_LARGEFILE64 and __USE_FILE_OFFSET64 macros. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- Changes v1->v2: - fix subject line docs/defines.txt | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/docs/defines.txt b/docs/defines.txt index b23fac9c0036..6af44bdd809f 100644 --- a/docs/defines.txt +++ b/docs/defines.txt @@ -10,11 +10,28 @@ __USE_GNU, __USE_BSD, __USE_XOPEN[2K], __USE_SVID, __USE_POSIX... If defined, user program which included us requests compat additions from relevant standard or Unix flavor. See features.h for full list. -__USE_FILE_OFFSET64 +_LARGEFILE_SOURCE + If defined, headers will provide functions fseeko and ftello. +_LARGEFILE64_SOURCE + If defined, headers will in addition to data types, constants and + functions named xxx (e.g. off_t, struct stat, F_SETLK, ftruncate()) + supply data types, constants and functions named xxx64 (e.g. off64_t, + struct stat64, F_SETLK64, ftruncate64()) known as an interface for + 64-bit file offsets. __USE_LARGEFILE[64] -_LARGEFILE[64]_SOURCE + Defined to 1 and used internally when built with _LARGEFILE[64]_SOURCE. + Undefined otherwise. + _FILE_OFFSET_BITS - ??? + Select default filesystem interface. When defined as 64 the data types, + constants and functions mentioned in _LARGEFILE64_SOURCE as xxx are + aliased to the corresponding xxx64 data types, constants and functions. + _FILE_OFFSET_BITS=64 enables both __USE_LARGEFILE and __USE_LARGEFILE64. + This flag does not affect the way libc itself is built, it only affects + what declarations are provided to library user. +__USE_FILE_OFFSET64 + Defined to 1 and used internally when built with _FILE_OFFSET_BITS=64. + Undefined otherwise. __THROW Function annotation "I do not throw anything". -- 2.11.0

1 0

[PATCH] dics/defines.txt: clarify LFS-related macros
by Max Filippov 10 May '19

10 May '19

Add description for _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, _FILE_OFFSET_BITS and __USE_LARGEFILE, __USE_LARGEFILE64 and __USE_FILE_OFFSET64 macros. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- docs/defines.txt | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/docs/defines.txt b/docs/defines.txt index b23fac9c0036..6af44bdd809f 100644 --- a/docs/defines.txt +++ b/docs/defines.txt @@ -10,11 +10,28 @@ __USE_GNU, __USE_BSD, __USE_XOPEN[2K], __USE_SVID, __USE_POSIX... If defined, user program which included us requests compat additions from relevant standard or Unix flavor. See features.h for full list. -__USE_FILE_OFFSET64 +_LARGEFILE_SOURCE + If defined, headers will provide functions fseeko and ftello. +_LARGEFILE64_SOURCE + If defined, headers will in addition to data types, constants and + functions named xxx (e.g. off_t, struct stat, F_SETLK, ftruncate()) + supply data types, constants and functions named xxx64 (e.g. off64_t, + struct stat64, F_SETLK64, ftruncate64()) known as an interface for + 64-bit file offsets. __USE_LARGEFILE[64] -_LARGEFILE[64]_SOURCE + Defined to 1 and used internally when built with _LARGEFILE[64]_SOURCE. + Undefined otherwise. + _FILE_OFFSET_BITS - ??? + Select default filesystem interface. When defined as 64 the data types, + constants and functions mentioned in _LARGEFILE64_SOURCE as xxx are + aliased to the corresponding xxx64 data types, constants and functions. + _FILE_OFFSET_BITS=64 enables both __USE_LARGEFILE and __USE_LARGEFILE64. + This flag does not affect the way libc itself is built, it only affects + what declarations are provided to library user. +__USE_FILE_OFFSET64 + Defined to 1 and used internally when built with _FILE_OFFSET_BITS=64. + Undefined otherwise. __THROW Function annotation "I do not throw anything". -- 2.11.0

1 0

[PATCH] xtensa: don't use l32r opcode explicitly
by Max Filippov 10 May '19

10 May '19

xtensa assembler is capable of representing register loads with either movi + addmi, l32r or const16, depending on the core configuration. Don't use '.literal' and 'l32r' directly in the code, use 'movi' and let the assembler relax them. Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- libc/string/xtensa/strcmp.S | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/libc/string/xtensa/strcmp.S b/libc/string/xtensa/strcmp.S index a16da5da2e92..a106bee675f5 100644 --- a/libc/string/xtensa/strcmp.S +++ b/libc/string/xtensa/strcmp.S @@ -37,11 +37,6 @@ .text .align 4 .literal_position - .literal .Lmask0, MASK0 - .literal .Lmask1, MASK1 - .literal .Lmask2, MASK2 - .literal .Lmask3, MASK3 - .literal .Lmask4, MASK4 ENTRY (strcmp) /* a2 = s1, a3 = s2 */ @@ -130,10 +125,9 @@ ENTRY (strcmp) .align 4 #if XCHAL_HAVE_LOOPS .Laligned: - .begin no-transform movi a11, 0 - l32r a4, .Lmask0 /* mask for byte 0 */ - l32r a7, .Lmask4 + movi a4, MASK0 /* mask for byte 0 */ + movi a7, MASK4 loop a11, .Laligned_done /* Loop forever. */ /* First unrolled loop body. */ @@ -184,10 +178,10 @@ ENTRY (strcmp) If not, loop over the rest of string using normal algorithm. */ bnone a8, a4, .Leq /* if byte 0 is zero */ - l32r a5, .Lmask1 /* mask for byte 1 */ - l32r a6, .Lmask2 /* mask for byte 2 */ + movi a5, MASK1 /* mask for byte 1 */ + movi a6, MASK2 /* mask for byte 2 */ bnone a8, a5, .Leq /* if byte 1 is zero */ - l32r a7, .Lmask3 /* mask for byte 3 */ + movi a7, MASK3 /* mask for byte 3 */ bnone a8, a6, .Leq /* if byte 2 is zero */ bnone a8, a7, .Leq /* if byte 3 is zero */ addi.n a2, a2, 4 /* advance s1 pointer */ @@ -196,7 +190,6 @@ ENTRY (strcmp) /* align (1 mod 4) */ loop a11, .Leq /* loop forever */ - .end no-transform l32i a8, a2, 0 /* get word from s1 */ l32i a9, a3, 0 /* get word from s2 */ -- 2.11.0

1 0

Re: [uclibc-ng-devel] uclibc-ng built with wrong _FILE_OFFSET_BITS
by Max Filippov 10 May '19

10 May '19

On Thu, May 9, 2019 at 11:34 AM Max Filippov <jcmvbkbc(a)gmail.com> wrote: > I've tried to run uclibc-ng tests on xtensa in a buildroot-built rootfs > and found misc/tst-preadvwritev failing with the following message: > > first buffer from first preadv different than expected > > Digging deeper into it I've found that the test is built with the following > definition in the command line: -D_FILE_OFFSET_BITS=64, > due to the following line in the uclibc-ng-test.mk: > > UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" > > but uclibc-ng itself does not have -D_FILE_OFFSET_BITS=64, > because of the following definition in the uclibc-ng.mk: > > UCLIBC_EXTRA_CFLAGS="$(TARGET_ABI)" > > uclibc-ng defaults to 32-bit off_t type then. > I'm not sure what's broken here, buildroot or uclibc-ng. Ideas? Ok, I see something definitely strange in the uclibc-ng: ublibc-ng does not honor -D_FILE_OFFSET_BITS=64 when it's passed to it in the make command, because the following fragment of the include/features.h that defines __USE_FILE_OFFSET64 based on the value of _FILE_OFFSET_BITS #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 # define __USE_FILE_OFFSET64 1 #endif is neutralized by the following fragment at the end of the same file: #ifdef _LIBC # undef _FILE_OFFSET_BITS # undef __USE_FILE_OFFSET64 # include <libc-internal.h> #endif -- Thanks. -- Max

2 2

Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)
by Vineet Gupta 02 May '19

02 May '19

On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote: >>> Auto-detecting system features: >>> ... dwarf: [ OFF ] >>> ... dwarf_getlocations: [ OFF ] >>> ... glibc: [ on ] >> Not related to current issue, this run uses a uClibc toolchain and yet it is >> detecting glibc - doesn't seem right to me. > Ok, I'll improve that, I think it just tries to detect a libc, yeah, > see: > > [acme@quaco linux]$ cat tools/build/feature/test-glibc.c > // SPDX-License-Identifier: GPL-2.0 > #include <stdlib.h> > > #if !defined(__UCLIBC__) > #include <gnu/libc-version.h> > #else > #define XSTR(s) STR(s) > #define STR(s) #s > #endif > > int main(void) > { > #if !defined(__UCLIBC__) > const char *version = gnu_get_libc_version(); > #else > const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__); > #endif > > return (long)version; > } > [acme@quaco linux]$ > > [perfbuilder@59ca4b424ded /]$ grep __GLIBC__ /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define __GLIBC__ 2 > /arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: ((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min)) > [perfbuilder@59ca4b424ded /]$ > > Isn't that part of uClibc? Right you are. Per the big fat comment right above that code, this gross hack in uclibc is unavoidable as applications tend to rely on that define. So a better fix would be to check for various !GLIBC libs explicitly. #ifdef __UCLIBC__ #elseif defined __MUSL__ ... Not pretty from app usage pov, but that seems to be the only sane way of doing it. -Vineet

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel May 2019