- devel - example.com

statfs call corrupts memory struct statfs too small
by Geoff Levand 29 Jun '18

29 Jun '18

Hi, I experienced seg faults due to stack corruption when calling statfs() with an automatic struct statfs variable. It seems there is a mismatch between the struct statfs used by libc and that used by the arm64 kernel. The call to statfs() writes 120 bytes, but struct statfs is only 88 bytes. The attached test program shows this. Building for arm64. libuClibc-1.0.30 kernel: Linux-4.17.3 Comparing these files: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre… https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/c… I see for the kernel all fields of struct statfs except f_fsid are the same length at 64 bits for arm64, and that gives 120 bytes. That differs from the libc version which has some 32 bit fields. I filed this bug over at buildroot, but it was suggested to report it here: https://bugs.busybox.net/show_bug.cgi?id=11121 The output of statfs-test program: sizeof statfs: 88 sizeof packed: 138 1: 94 94 2: 19 19 3: 2 2 4: 1 1 5: 0 0 6: 0 0 7: 0 0 8: 0 0 9: 0 0 10: 10 10 11: 0 0 12: 0 0 13: 0 0 14: 0 0 15: 0 0 16: 0 0 17: 72 72 18: a5 a5 19: 7 7 20: 0 0 21: 0 0 22: 0 0 23: 0 0 24: 0 0 25: 83 83 26: 80 80 27: 7 7 28: 0 0 29: 0 0 30: 0 0 31: 0 0 32: 0 0 33: 83 83 34: 80 80 35: 7 7 36: 0 0 37: 0 0 38: 0 0 39: 0 0 40: 0 0 41: 72 72 42: a5 a5 43: 7 7 44: 0 0 45: 0 0 46: 0 0 47: 0 0 48: 0 0 49: d9 d9 50: a0 a0 51: 7 7 52: 0 0 53: 0 0 54: 0 0 55: 0 0 56: 0 0 57: 0 0 58: 0 0 59: 0 0 60: 0 0 61: 0 0 62: 0 0 63: 0 0 64: 0 0 65: ff ff 66: 0 0 67: 0 0 68: 0 0 69: 0 0 70: 0 0 71: 0 0 72: 0 0 73: 0 0 74: 10 10 75: 0 0 76: 0 0 77: 0 0 78: 0 0 79: 0 0 80: 0 0 81: 20 20 82: 0 0 83: 0 0 84: 0 0 85: 0 0 86: 0 0 87: 0 0 88: 0 0 89: 0 0 90: 0 0 91: 0 0 92: 0 0 93: 0 0 94: 0 0 95: 0 0 96: 0 0 97: 0 0 98: 0 0 99: 0 0 100: 0 0 101: 0 0 102: 0 0 103: 0 0 104: 0 0 105: 0 0 106: 0 0 107: 0 0 108: 0 0 109: 0 0 110: 0 0 111: 0 0 112: 0 0 113: 0 0 114: 0 0 115: 0 0 116: 0 0 117: 0 0 118: 0 0 119: 0 0 120: 0 0 121: ff cc 122: ff cc 123: ff cc 124: ff cc 125: ff cc 126: ff cc 127: ff cc 128: ff cc 129: ff cc 130: ff cc 131: ff cc 132: ff cc 133: ff cc 134: ff cc 135: ff cc 136: ff cc 137: ff cc 138: ff cc -Geoff

2 2

[PATCH v2] ldso/arc: fix LD_DEBUG segv when printing R_ARC_NONE
by Vineet Gupta 27 Jun '18

27 Jun '18

Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> --- v2: Also remove a bogus trailing l in prints --- ldso/ldso/arc/elfinterp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ldso/ldso/arc/elfinterp.c b/ldso/ldso/arc/elfinterp.c index 5a02bc2348da..a30c19bcb832 100644 --- a/ldso/ldso/arc/elfinterp.c +++ b/ldso/ldso/arc/elfinterp.c @@ -64,7 +64,7 @@ _dl_linux_resolver(struct elf_resolve *tpnt, unsigned int plt_pc) if (_dl_debug_bindings) { _dl_dprintf(_dl_debug_file, "\nresolve function: %s", symname); if (_dl_debug_detail) - _dl_dprintf(_dl_debug_file, "\n\tpatched %x ==> %pc @ %pl\n", + _dl_dprintf(_dl_debug_file, "\n\tpatched %x ==> %pc @ %p\n", *got_addr, new_addr, got_addr); } @@ -178,7 +178,7 @@ _dl_do_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope, log_entry: #if defined __SUPPORT_LD_DEBUG__ - if (_dl_debug_detail) + if (_dl_debug_detail && (reloc_type != R_ARC_NONE)) _dl_dprintf(_dl_debug_file,"\tpatched: %x ==> %x @ %x", old_val, *reloc_addr, reloc_addr); #endif @@ -214,7 +214,7 @@ _dl_do_lazy_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope, } #if defined __SUPPORT_LD_DEBUG__ - if (_dl_debug_reloc && _dl_debug_detail) + if (_dl_debug_reloc && _dl_debug_detail && (reloc_type != R_ARC_NONE)) _dl_dprintf(_dl_debug_file, "\tpatched: %x ==> %x @ %x\n", old_val, *reloc_addr, reloc_addr); #endif -- 2.7.4

1 0

[PATCH] ldso/arc: fix LD_DEBUG segv when printing R_ARC_NONE
by Vineet Gupta 27 Jun '18

27 Jun '18

Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com> --- ldso/ldso/arc/elfinterp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ldso/ldso/arc/elfinterp.c b/ldso/ldso/arc/elfinterp.c index 5a02bc2348da..17d588899dfc 100644 --- a/ldso/ldso/arc/elfinterp.c +++ b/ldso/ldso/arc/elfinterp.c @@ -178,7 +178,7 @@ _dl_do_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope, log_entry: #if defined __SUPPORT_LD_DEBUG__ - if (_dl_debug_detail) + if (_dl_debug_detail && (reloc_type != R_ARC_NONE)) _dl_dprintf(_dl_debug_file,"\tpatched: %x ==> %x @ %x", old_val, *reloc_addr, reloc_addr); #endif @@ -214,7 +214,7 @@ _dl_do_lazy_reloc(struct elf_resolve *tpnt, struct r_scope_elem *scope, } #if defined __SUPPORT_LD_DEBUG__ - if (_dl_debug_reloc && _dl_debug_detail) + if (_dl_debug_reloc && _dl_debug_detail && (reloc_type != R_ARC_NONE)) _dl_dprintf(_dl_debug_file, "\tpatched: %x ==> %x @ %x\n", old_val, *reloc_addr, reloc_addr); #endif -- 2.7.4

1 0

write is not weak?
by Christophe Lyon 25 Jun '18

25 Jun '18

Hi, While working on FDPIC support for ARM in uclibc-ng, I've noticed that the write() function if defined as a strong global symbol, while the __GI_write alias is weak. 00000034 w F .text 0000005c .hidden __GI_write 00000034 g F .text 0000005c write my pre-processed write.i contains: ssize_t __attribute__ ((weak)) write (int fd, const void *buf, size_t count) { int oldtype; ssize_t result; if (__builtin_expect (__libc_multiple_threads == 0, 1)) return __write_nocancel (fd, buf, count); oldtype = __libc_enable_asynccancel (); result = __write_nocancel (fd, buf, count); __libc_disable_asynccancel (oldtype); return result; } extern __typeof (write) __EI_write __asm__("" "write"); extern __typeof (write) __EI_write __attribute__((alias ("" "__GI_write"))); and write.s has: .weak __GI_write .hidden __GI_write .type __GI_write, %function __GI_write: .fnstart [...] .size __GI_write, .-__GI_write .global write .set write,__GI_write >From the .i file, I'd expect the weak attribute to be set on write. FWIW, I'd like write to be weak, because currently it prevents re-defining it user code and linking statically with libc.a I've checked that glibc and newlib have weak write. Since this seems to depend on the threads model, my .config has: # HAS_NO_THREADS is not set UCLIBC_HAS_LINUXTHREADS=y UCLIBC_HAS_THREADS_NATIVE=y UCLIBC_HAS_THREADS=y PTHREADS_DEBUG_SUPPORT=y and having # UCLIBC_HAS_LINUXTHREADS is not set has no effect on write's weakness. What am I missing? Thanks, Christophe

2 3

__WIFSTOPPED macro for MIPS
by Sergey Korolev 14 Jun '18

14 Jun '18

Does anyone know why __WIFSTOPPED macro redefined for MIPS architecture as #if !defined(__mips__) #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f) #else #define __WIFSTOPPED(status) (((status) & 0xff) == 0x7f && ((status) & 0xff00)) #endif ? The problem with this definition is in that newer gdb versions (>= 7.0) expect that WIFSTOPPED(W_STOPCODE(0)) is true (see [1]), otherwise a debugger erroneously blocks a child process in a trace status until gdb exit. In the glibc [2] this macro expansion is the same for all architectures. Is this a gdb or uClibc-ng bug? 1. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; a=blob;f=gdb/linux-nat.c;h=445b59fa4adadbb2890a9e2debffb5 330f1e09e4;hb=HEAD#l497 2. https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob; f=bits/waitstatus.h;h=a1c232612cd13e758f222ade6b27bc2c85ab8f8f;hb=HEAD#l44

3 2

[PATCH 1/1] remove unused assembler functions for arm
by Florian La Roche 12 Jun '18

12 Jun '18

These assembler functions seem to be unused/referenced, so we can remove them completely. Signed-off-by: Florian La Roche <Florian.LaRoche(a)googlemail.com> --- ldso/ldso/arm/thumb_atomics.S | 78 ----------------------------------- 1 file changed, 78 deletions(-) delete mode 100644 ldso/ldso/arm/thumb_atomics.S diff --git a/ldso/ldso/arm/thumb_atomics.S b/ldso/ldso/arm/thumb_atomics.S deleted file mode 100644 index f88da2b9c..000000000 --- a/ldso/ldso/arm/thumb_atomics.S +++ /dev/null @@ -1,78 +0,0 @@ -/* Copyright (C) 2006 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - In addition to the permissions in the GNU Lesser General Public - License, the Free Software Foundation gives you unlimited - permission to link the compiled version of this file with other - programs, and to distribute those programs without any restriction - coming from the use of this file. (The GNU Lesser General Public - License restrictions do apply in other respects; for example, they - cover modification of the file, and distribution when not linked - into another program.) - - Note that people who make modified versions of this file are not - obligated to grant this special exception for their modified - versions; it is their choice whether to do so. The GNU Lesser - General Public License gives permission to release a modified - version without this exception; this exception also makes it - possible to release a modified version which carries forward this - exception. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, see - <http://www.gnu.org/licenses/>. */ - -#include <features.h> - -#ifdef __UCLIBC_HAS_THREADS_NATIVE__ - -#include <sysdep.h> - -#if defined __thumb__ - -/* Out-of-line atomic operations that we can't do in Thumb mode. - This ends up in various libraries where it is needed (and - a few .a archives where it isn't). */ - - .hidden __thumb_swpb -ENTRY (__thumb_swpb) - swpb r0, r0, [r1] - bx lr -END (__thumb_swpb) - - .hidden __thumb_swp -ENTRY (__thumb_swp) - swp r0, r0, [r1] - bx lr -END (__thumb_swp) - - .hidden __thumb_cmpxchg -ENTRY (__thumb_cmpxchg) - stmdb sp!, {r4, lr} - mov r4, r0 -0: ldr r3, [r2] - cmp r3, r4 - bne 1f - mov r0, r4 - mov r3, #0xffff0fff - mov lr, pc - add pc, r3, #(0xffff0fc0 - 0xffff0fff) - bcc 0b - mov r3, r4 -1: mov r0, r3 - ldmia sp!, {r4, pc} -END (__thumb_cmpxchg) - -#endif /* __thumb__ */ -#endif /* __UCLIBC_HAS_THREADS_NATIVE__ */ - -- 2.17.0

2 1

_FILE_OFFSET_BITS=64 and preadv/pwritev prototypes
by Sergey Korolev 11 Jun '18

11 Jun '18

As preadv and pwritev accept off_t type the prototypes should be declared as follows extern ssize_t preadv (int __fd, const struct iovec *__iovec, int __count, off_t __offset) __wur; extern ssize_t pwritev (int __fd, const struct iovec *__iovec, int __count, off_t __offset) __wur; to take into account _FILE_OFFSET_BITS=64 define. I am not sure but probably it is better to redeclare these prototypes by analogy with sendfile using __REDIRECT_NTH.

2 2

Re: [uclibc-ng-devel] thumb_swp/thumb_swpb
by Florian La Roche 04 Jun '18

04 Jun '18

1 0

thumb_swp/thumb_swpb
by Florian La Roche 30 May '18

30 May '18

Hello uclibc-ng/buildroot developers, compiling buildroot with thumb-instructions and gcc-8.1 results in an error due to the swp{,b} assembler instruction. Searching within buildroot, this thumb_swp* function is never used anywhere (but this is a very limited search). The add commit message for this refers to other libraries using this function, but no real specific data. Maybe this can be removed altogether? best regards, Florian La Roche Geschäftsführung: Susanne Kunschert, Thomas Pilz Pilz GmbH & Co. KG, Sitz: Ostfildern, HRA 210 893, Amtsgericht Stuttgart Kompl. Ges. Peter Pilz GmbH, Sitz: Ostfildern, HRB 210 612, Amtsgericht Stuttgart Umsatzsteuer: ID-Nr. DE 145 355 773, WEEE-Reg.-Nr. DE 71636849 This email is intended solely for the use of the named address(es). Any unauthorised disclosure, copying or distribution of these confidential information contained therein, or the taking of any action based on it, is prohibited. The sender disclaims any liability for the integrity of this email. Legally binding declarations must be in written form. Umweltschutz liegt uns am Herzen! - Bitte denken Sie an unsere Umwelt, bevor Sie diese E-Mail drucken. We do care about the environment! - Please consider the environment before printing this e-mail.

2 2

Creating a pull request
by Daniel Dubinsky 29 May '18

29 May '18

Hello, Sorry for the bother but I’ve been struggling with compiling uclibc-ng. All I did was clone; make defconfig; make. I get the following error: CC ldso/ldso/ldso.oS In file included from ./include/bits/posix1_lim.h:152:0, from ./include/limits.h:144, from ./include/sys/param.h:25, from ./ldso/include/ldso.h:43, from ldso/ldso/ldso.c:32: ./include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file or directory compilation terminated. Makerules:370: recipe for target 'ldso/ldso/ldso.oS' failed make: *** [ldso/ldso/ldso.oS] Error 1 I’ve tried to remove -nostdinc, the compilation then proceeds but with no success. I also tried to install the following packages: kernel-package, linux-libc-dev, binutils, libc-dev-bin, linux-headers-4.10.0-35 and linux-headers-generic. Can anyone help? Best regards, Daniel Dubinsky

2 3