LLEXT: support detached sections #79012
Conversation
zephyrbot
added
area: llext
include/zephyr/llext/llext.h
Outdated
| @@ -139,6 +139,7 @@ struct llext_load_param { | |||
|
|
|||
| /** Default initializer for @ref llext_load_param */ | |||
| #define LLEXT_LOAD_PARAM_DEFAULT { .relocate_local = true, } | |||
| const void *llext_loaded_sect_ptr(struct llext_loader *ldr, struct llext *ext, unsigned int sh_ndx); | |||
There was a problem hiding this comment.
I understand this was done to access this from code in arch/. That is fine, but please move this to a new llext_internal.h file in this folder, so it's explicitly not part of the public API.
subsys/llext/llext_load.c
Outdated
| if (pre_located && shdr->sh_addr < LLEXT_SECTION_MIN_ADDR) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Why do addresses below a certain value get ignored?
I think this is very project-specific. Should we have callback functions to provide this kind of customizations?
There was a problem hiding this comment.
this is basically a NULL area. I use 0 as a base for sections without pre-defined run-time location, but since there can be several such sections, some of them get other low addresses
subsys/llext/llext_load.c
Outdated
| const char *s_name = llext_string(ldr, ext, LLEXT_MEM_SHSTRTAB, | ||
| shdr->sh_name); | ||
|
|
||
| if (pre_located && section_addr >= LLEXT_SECTION_MIN_ADDR) { |
There was a problem hiding this comment.
This also feels specific - although maybe a per-section flag could work (I assume they are the sections not ignored by the above check).
subsys/llext/llext_load.c
Outdated
| @@ -36,8 +36,21 @@ LOG_MODULE_DECLARE(llext, CONFIG_LLEXT_LOG_LEVEL); | |||
| * calls, taking into account if the load process was successful or not. | |||
| */ | |||
|
|
|||
| #define LLEXT_SECTION_MIN_ADDR 0x10000 | |||
There was a problem hiding this comment.
This hardcoded value is neither arch- nor even project- independent. If comparing addresses is required, then this must at least be customizable by the caller.
There was a problem hiding this comment.
@pillo79 agree, yes, I was thinking about it too. Would it be ok for you to pass this as a value in struct llext_load_param? Otherwise we could add a platform callback to that structure to perform any testing and return true or false for whether the symbol is used where it's located or where it's linked for, but I think that would make it uglier, less transparent.
There was a problem hiding this comment.
I personally see it as the opposite - it would neatly decouple the generic implementation from project-specific reasoning.
For example, I can already see places where I would add callbacks for:
- "do we allocate a copy of a section?" <- would replace and extend
STORAGE_WRITABLE, e.g. allowrodatafrom Flash - "how do we relocate a section?" <- would extend (or even replace!)
pre_locatedand simplify the current PR - "what is the effective base address of this section?" <- would possibly replace link scripts and also be a first step for in-Flash XIP.
These would be entirely optional, at the app developer's discretion, to allow advanced users like SOF to customize the linking behavior while keeping the default unchanged.
lyakh
force-pushed
the
llext
branch
2 times, most recently
from
90e4704
to
799a5b3
Compare
Make llext_loaded_sect_ptr() a proper function to be able to call it from platform LLEXT code. Signed-off-by: Guennadi Liakhovetski <[email protected]>
It's more common in the LLEXT code base to call elf_sym_t instances "sym" and not "sym_tbl." Convert llext_link_plt() to follow this convention. Signed-off-by: Guennadi Liakhovetski <[email protected]>
When building LLEXT for Xtensa with custom sections the compiler can leave unresolved references in them. Then this has to be done by the LLEXT core during linking. This commit adds linking support for the L32R Xtensa instruction. Signed-off-by: Guennadi Liakhovetski <[email protected]>
To simplify LLEXT loader parameter extension pass the whole struct llext_load_param to final consumers instead of extracting individual fields from it in the caller function. Signed-off-by: Guennadi Liakhovetski <[email protected]>
Some LLEXT objects can include sections, that should not be merged with other sections of the same type. E.g. when such sections should be placed into locations, other than the default. Add support for such sections. Signed-off-by: Guennadi Liakhovetski <[email protected]>
SOF loads LLEXT objects into slower IMR memory but they're partially pre-linked for SRAM, where objects will be copied to after linking by LLEXT core. But some sections should not be copied to SRAM and be used in IMR directly. This PR adds support for such sections.