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
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
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
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.
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.
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
Hi,
as after every uClibc-ng release I try to run a full build and
try to generate test results of the release:
https://downloads.uclibc-ng.org/reports/1.0.30/
The toolchains for ARC architecture where back to Synopsys
arc-2018.03-rc1 instead of binutils/gcc from pstream.
There we can see that the results for ARCv2 are getting better and
under or equal 10 failures. The ARCv1 results are bad. (over 40).
The newly added test results for c-sky are not bad, just ck610 seems
to generate a lot of Bus errors.
The other results showing no major regressions. The empty toolchain
files are just a marker, that a toolchain could be produced without
any runtime testing.
The default Linux kernel used was bumped to 4.14 series.
best regards
Waldemar
These should be going to the list for archiving, so I'm forwarding it.
On 4/29/18 8:32 AM, Dave Flogeras wrote:
> Hey Anthony,
>
> Also I'd like to chime in what I learned during testing: since this release
> of uclibc-ng-1.0.30 removes arcfour, rebuilding at least openssl/openssh
> immediately might warrant a huge warning for upgrading Gentoo users. My
> system is built on one machine and deployed as binaries onto the target, so
> having a non-working SSH/rsync after upgrading uclibc-ng is a bummer.
> Portage (Python) also squawks when importing a module until python is
> rebuilt, but it doesn't seem to prevent portage from working.
>
> Dave
>
> On Sun, Apr 29, 2018 at 6:24 AM, Waldemar Brodkorb <wbx(a)uclibc-ng.org>
> wrote:
>
>> Hi Anthony,
>>
>> Dave and I fixed the dlclose() issue and we think it could
>> be a good time to have new stage3 with 1.0.30?
>> I can test on real hardware for every supported architecture.
>>
>> Thanks in advance
>> Waldemar
>>
>>
>
Yes I noticed that, and it is serious, but this is the least of my
worries right now. The LDPATH search is totally broken on amd64.
ldconfig shows that libstdc++.so and libgcc_s.so are in the search path:
# ldconfig -p | grep libstdc++.so
libstdc++.so.6 (libc0) =>
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so.6
libstdc++.so (libc0) =>
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so
# ldconfig -p | grep libgcc_s.so
libgcc_s.so.1 (libc0) =>
/usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libgcc_s.so.1
And yet a test c++ program cannot locate those libraries:
# ldd test
libstdc++.so.6 => not found
libgcc_s.so.1 => not found
libc.so.0 => /lib//libc.so.0 (0x7f6bfb067000)
ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x7f6bfb516000)
@Waldemar, the issue is not anything you suggested in your previous
email. What might you have touched in ld64-uClibc.so or libc.so itself
that would affect the search path? If its any help, I hit the dlclose()
issue many years ago (and might have been the first to report it, I'm
not sure). There was some size issue wrt 64 vs 32 that cause an issue
there. I wonder if in fixing that maybe you broke LDPATH?
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness(a)gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
