Age | Commit message (Collapse) | Author |
|
The Linux kernels ELF-FDPIC binfmt program loader can support loading and
running conventional ELF format binaries on noMMU kernels when compiled
appropriately. That is when they are constant displacement binaries such
as generated using the -pie compile option.
Add a configure option to allow selecting ELF binary support in noMMU
mode configurations on architectures that support this. The main
requirement is to generate the ldso run-time loader to perform relocation
at load time. These configurations do not support shared libraries, so
there is no need to generate a full shared library, only the static
version is required.
The use of ELF format binaries does mean a slightly simpler toolchain
generation (does not require a -uclinux- for some architectures) and does
not require an extra tool like elf2flt.
This initial support targets M68K, ARM and RISC-V architectures. No kernel
changes are required, the required support for this is already in mainline
kernels (certainly as of linux-6.6).
Note that for the M68K and ARM architectures that the initialized
registers and stack layout at process startup is slightly different for
the flat format loader and the ELF/ELF-FDPIC loaders. So we need some
changes to the startup code (crt1.S) for them.
I have not done extensive testing outside of M68K, ARM and RISC-V.
I had to make changes to a couple of the dl-startup.h architecture files
to get them to build for this noMMU case. I did not dig down too deep on
the reasons, but they still seem ok for the MMU case as well.
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
|
|
* extra/Configs/Config.in.arch: Add TARGET_arm to the target list
for UCLIBC_FORMAT_FDPIC_ELF.
Signed-off-by: Mickaël Guêné <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
|
|
|
|
|
|
If you enable these wrappers, be sure you don't need long double
precision on your embedded device, as these only enables
long double warpper functions to the existing double math
functions. Required to build some software as lvm2.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
|
|
Ported over from GNU C Library and runtime tested in Qemu.
|
|
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
|
|
The FR-V port is really broken, and I have no emulator
or hardware for this platform. I tried to get some hardware
from RedHat, who made the FR-V port initially. Unfortunately
Fujitsi didn't agreed to sent me some of their unused spare
hardware lying @RedHat. As I invested some time to get stuff compiled,
I decided to add the code and may be anytime later I can gain
access to some emulator or hardware.
GDB simulator for FR-V doesn't support booting Linux AFAIK.
|
|
Fixes SH build breakage due to attempts to define hidden defs for
unavailable long double functions.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Linuxthreads(old and new) need deprecated syscalls to build. Existing
architectures support these system calls but new architectures don't.
This symbol has no functional change apart from hidding the Linuxthreads
symbols from arches that don't support them.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Setting KERNEL_HEADERS up to the exact path all the time is a pita,
especially when the toolchain is often times already configured to
do the right thing. So if the user has set that to "", don't force
any specific paths.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
kconfig's default defaults to n so spelling out default n is redundant
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Unused option (and is in !ARCH_HAS_MMU guarded section, but depends on ARCH_HAS_MMU)
Signed-off-by: Peter S. Mazinger <ps.m@gmx.net>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Ryan Flux <ryan.flux@emsolutions.com.au>
Signed-off-by: Steve Bennett <steveb@workware.net.au>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
UCLIBC_HAS_FLOATS and UCLIBC_HAS_FPU are denoting two different aspects.
UCLIBC_HAS_FLOATS covers the floating point operations which has nothing
to do if you have FPU or not.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
This adds support for the TI C6X family of processors.
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Aurelien Jacquiot <a-jacquiot@ti.com>
Signed-off-by: Bernd Schmidt <bernds@codesourcery.com>
|
|
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
This reverts commit 6625518cd6894338937a74ca6b9187b7b8167b03.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Default is now the native arch, you can start a fresh .config via
'make ARCH=ia64 menuconfig'.
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
The sbrk() function can be used to merely query sizes and for that, no-mmu
works the same as mmu. It can also sometimes increase data segments on
no-mmu systems provided the trailing memory is free. So, there is no real
reason to exclude this function for no-mmu ports.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
|
|
i387 works (could be that it works on x86_64, untested), sse code disabled.
|
|
|
|
|
|
|
|
for i386. UCLIBC_HAS_FENV
|
|
|
|
|
|
may need to update their paths slightly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pointed out by Joseph S. Myers
|
|
|
|
namespace
|
|
|
|
|
|
|
|
|
|
|
|
items, we have to declare what endianness cpus are capable of supporting
and work using dependancies.
|
|
are implemented in hardware or via kernel emulation doesn't matter to
the libc code.
|