| Age | Commit message (Collapse) | Author |
|---|
|
|
|
default
This patch fixes segfault of all user space processes (including init, which caused a panic) on recent buildroot powerpc32 builds.
The issue has been reported by Romain Naour in this thread: https://mailman.uclibc-ng.org/pipermail/devel/2021-May/002068.html
Recent buildroot toolchain enables secure PLT in powerpc gcc.
The latter will then supply -msecure-plt to gas invocations by default.
Recent buildroot also enables PIE by defaults.
For the secure PLT to work in PIC, the r30 register needs to point to the GOT.
Old "bss plt" was just a one-instruction-wide PLT slot, pointed-to by a R_PPC_JMP_SLOT relocation, which was written on-the-fly to contain a branch instruction to the correct address. It therefore had to stay writable.
New secure PLT only contains read-only code which loads the branch address from the writable GOT.
Note: secure PLT without PIC does not need r30 to be set. Because offset between plt stub code and got is known at link-time. In this case the PLT entry looks like:
1009b3e0 <__uClibc_main@plt>:
1009b3e0: 3d 60 10 0e lis r11,4110
1009b3e4: 81 6b 03 74 lwz r11,884(r11)
1009b3e8: 7d 69 03 a6 mtctr r11
1009b3ec: 4e 80 04 20 bctr
Whereas secure PLT with PIC - offset between plt and got is unknown at link-time - looks like this:
000af800 <00000000.plt_pic32.__uClibc_main>:
af800: 81 7e 03 80 lwz r11,896(r30)
af804: 7d 69 03 a6 mtctr r11
af808: 4e 80 04 20 bctr
af80c: 60 00 00 00 nop
Signed-off-by: Yann Sionneau <yann@sionneau.net>
|
|
|
|
|
|
|
|
This commit adds support for Kalray VLIW family (kvx)
Kalray kv3 core is embedded in Kalray Coolidge SoC. This core which is the
third of the KV family has the following features:
32/64 bits execution mode
6-issue VLIW architecture
64 x 64bits general purpose registers
SIMD instructions
little-endian
In order to build a usable toolchain, build scripts are provided at the
following address: https://github.com/kalray/build-scripts.
Kalray uses FOSS which is available at https://github.com/kalray
This includes Linux kernel, uClibc-ng, gcc, binutils, etc.
Signed-off-by: Clément Léger <cleger@kalray.eu>
Signed-off-by: Guillaume Thouvenin <gthouvenin@kalray.eu>
Signed-off-by: Laurent Thevenoux <lthevenoux@kalray.eu>
Signed-off-by: Marc Poulhies <mpoulhies@kalray.eu>
Signed-off-by: Marius Gligor <mgligor@kalray.eu>
Signed-off-by: Yann Sionneau <ysionneau@kalray.eu>
|
|
|
|
|
|
|
|
As described in https://bugs.busybox.net/show_bug.cgi?id=12801 the
check for '-Wa,--noexecstack' is not working since binutils 2.31.x.
This fix adapts the approach already taken with check_ld and uses a
temporary file. Further, check_gcc is also adapted to avoid future
problems.
Signed-off-by: Marcel Patzlaff <m.patzlaff@pilz.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Under Fedora 27 there is a problem with the existing ld check.
Binutils ld segfaults. Add a glibc compat macro to complete
the build on Fedora.
Signed-off-by: Sven Anders <anders@anduras.de>
|
|
|
|
|
|
Pass the -mcpu and -mhard-float from UCLIBC_EXTRA_CFLAGS instead.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
|
|
|
|
Follow the steps to build c-sky uclibc linux system:
1. git clone https://github.com/c-sky/buildroot.git
2. cd buildroot
3. make qemu_csky_ck810_uclibc_defconfig
4. make
Follow the buildroot/board/qemu/csky/readme.txt to run.
This buildroot toolchain is pre-build, But you can rebuild
the c-sky uclibc-ng alone and install it to the buildroot
sysroot manually.
We'll try our best to improve the uclibc-ng continuously.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
|
|
|
|
|
|
|
|
|
|
Either toolchain defaults or buildsystems should provide the
architecture specific CFLAGS and LDFLAGS.
|
|
|
|
Ported over from GNU C Library and runtime tested in Qemu.
|
|
|
|
|
|
|
|
This is because some old ARC750 cores lack these instructions.
We now rely on the default for the toolchain driver:
-mcpu=A7 won't enable those, while -mcpu=archs will as these
instructions are baseline (and thus is not impacted with this change).
If some arc700 based cpu does have them, it can override the driver
defaults in it's one level up build system.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
gcc 4.8 does not support nan flag.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
|
|
|
|
|
Similar to musl libc a single libc has many benefits and solves
some open issues with uClibc-ng.
- no pthread_mutex_* weak symbols exported anymore
- applications no longer failing to link when either
-lrt or -lpthread are missing for dynamic and static linking mode
- smaller C library
- slightly better runtime performance
|
|
A single test with targeting ARM showed that this feature
seems bit rotted. Remove DOMULTI and simplify Makefiles.
|
|
|
|
Add -Wdeclaration-after-statement when EXTRA_WARNINGS is enabled.
|
|
|
|
|
|
|
|
Add support for Andes Technology NDS32 architecture.
See here http://www.andestech.com/en/index/index.htm for more
informaton. Verification of the port from an older uClibc
port was done on a sponsored AG101p board.
The testsuite only has 5 errors, three are related to
an existing bug in dlclose() with LT.old, also happening
on cris32 and m68k.
Failures to fallocate/posix_fallocate are unresolved.
Thanks to Andes Technology sponsoring the hardware and
being very helpful while doing the uClibc-ng porting.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
"-msoft-float" makes no sense for ARC because there's no such thing
as "-mhard-float" on ARC. Instead we use our own "-mfpu=XXX" option
when a particular floating-point related HW feature is enabled in
the ARC core.
We used to live with that phony option for quite some time but
with migration to newer GCC following warning now appears:
-------------------->8-----------------
arc-linux-gcc: warning: ‘-msoft-float’ is deprecated
cc1: warning: ‘-msoft-float’ is deprecated [enabled by default]
-------------------->8-----------------
And that warning gets printed for each invocation of gcc with
the option in question, which makes compilation output barely
readable.
So we disable that phony option for ARC now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Waldemar Brodkorb <wbx@uclibc-ng.org>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
|
|
|
|
Both $(CC_FLAG_ASNEEDED) and $(CC_FLAG_NO_ASNEEDED) never become "y",
must check for non-empty strings.
To keep make 3.80 compatibility "$(if" used only.
Fixes: 7da4d1e7 "buildsys: do not use $(and)".
Signed-off-by: Leonid Lisovskiy <lly.dev@gmail.com>
|
|
Linuxthreads.new isn't really useful with the existence
of NPTL/TLS for well supported architectures. There is no
reason to use LT.new for ARM/MIPS or other architectures
supporting NPTL/TLS. It is not available for noMMU architectures
like Blackfin or FR-V. To simplify the live of the few uClibc-ng
developers, LT.new is removed and LT.old is renamed to LT.
LINUXTHREADS_OLD -> UCLIBC_HAS_LINUXTHREADS
|
|
|
|
Currently, the Thumb support on ARM has three related Config.in
options, which are not trivial for users to understand, and are in
fact not needed:
- The USE_BX option is not needed: knowing whether BX is available or
not is easy. If you have an ARM > v4 or ARMv4T, then BX is
available, otherwise it's not. This is the logic used in glibc.
- The USE_LDREXSTREX option is not needed: whenever Thumb2 is
available, ldrex/strex are available, so we can simply rely on
__thumb2__ to determine whether ldrex/strex should be used, without
requiring a Config.in option.
- Once USE_BX and USE_LDREXSTREX are removed, the only thing left
that COMPILE_IN_THUMB does is to set -mthumb. This makes the option
unnecessary, as on ARM at least, the user is already supposed to
pass -march=<foo> or other compiler options tuning the library for
a specific ARM variant. There is no reason to do otherwise for
Thumb, which allows to get rid of the COMPILE_IN_THUMB option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
