Add support for generating llext veneers for Arm baseline cores.
The veneer is AAPCS-compliant: r0-r3, r5-r11 and LR are preserved,
r4 is saved and restored, and only r12 (ip) is clobbered as
permitted by AAPCS.
Tested on RP2040 (Cortex-M0+) loading an extension that calls
__gnu_thumb1_case_uqi.
Signed-off-by: Ibrahim Abdalkader <i.abdalkader@gmail.com>
When an LLEXT is loaded in memory and calls kernel or libc symbols
located in flash, the target may fall outside the range of branches
on some architectures, such as Thumb-2 BL, causing relocations to
fail.
Add CONFIG_LLEXT_VENEERS which, when enabled, generates trampoline
stubs for such out-of-range relocations.
Stubs are allocated from the LLEXT heap into a new LLEXT_MEM_VENEER
region, instead of using new state variables to track the memory, to
leverage the existing llext machinery that flushes cache, frees memory
on unload, etc.
A test extension is added, compiled with -mno-long-calls to force
direct branches on Arm and exercise the veneer path against multiple
libc symbols.
Signed-off-by: Ibrahim Abdalkader <i.abdalkader@gmail.com>
This relocation is used by the ARM TLS code to access thread local
variables. It is a simple absolute relocation that adds the symbol's
offset to the value at the location. This allows the code to access
thread local variables using a fixed offset from the thread pointer,
which is determined at runtime.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
The RISC-V port of llext requires additional parameters for
handling non-adjacent HI20/LO12 relocations in arch_elf_relocate():
the current extension (struct llext), the current extension loader
(struct llext_loader), the current section header (elf_shdr_t) and
the current symbol (elf_sym_t).
This changes the signature of arch_elf_relocate accordingly.
Signed-off-by: Eric Ackermann <eric.ackermann@cispa.de>
Adds support for all relocation type produced by GCC
on ARM platform using partial linking (-r flag) or
shared link (-fpic and -shared flag).
Signed-off-by: Cedric Lescop <cedric.lescop@se.com>
Add support for the relocation type R_ARM_ARM_THM_CALL which is
produced for the ARM Thumb BL and BLX (branch immediate)
instructions.
These instructions are used for non-static functions like
void test1(void)
{
}
void main(void)
{
test1();
}
Without support for this relocation, test1() has to be static.
Signed-off-by: Bjarki Arge Andreasen <bjarki@arge-andreasen.me>
The opval argument of arch_elf_relocate() was modified by
adding the value stored at opaddr before passing it to
arch_elf_relocate(). This presumed that the addend would
always be stored as a raw value at opaddr, which is not the
case for all relocation types.
This PR modifies opval to be the absolute address of opval,
and moves the addition of the addend from llext_link_plt()
to the implementation of arch_elf_relocate().
Signed-off-by: Bjarki Arge Andreasen <bjarki@arge-andreasen.me>
elf_rela_t contains elf_rel_t exactly and contains an additional
field at the end. Therefore pointers of that type can be used for
both types, making the code generic.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
There were a few small nits that were pointed out in the initial PR.
Fixes the LOG_ macro in the arm elf implementation, replaces a few stray
mentions of modules in llext.h with extensions.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Adds the linkable loadable extensions (llext) subsystem which provides
functionality for reading, parsing, and linking ELF encoded executable
code into a managed extension to the running elf base image.
A loader interface, and default buffer loader implementation,
make available to the llext subsystem the elf data. A simple management
API provide the ability to load and unload extensions as needed. A shell
interface for extension loading and unloading makes it easy to try.
Adds initial support for armv7 thumb built elfs with very specific
compiler flags.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
Co-authored-by: Chen Peng1 <peng1.chen@intel.com>
Co-authored-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
