mirror of
https://github.com/apache/nuttx.git
synced 2026-10-02 03:46:25 +00:00
1aa32bbc07
An ET_DYN object is loaded into one allocation with its data behind its text, because its data references sit at a fixed distance from the code that makes them. An FDPIC object does not work that way: it reaches its data through a base register, so the two segments can be placed wherever suits, and the point of the format is that the read-only one is left on the media and executed there while only the writable one is copied. One copy of the text then serves every instance. So libelf_load() grows a second case. The object announces itself in the OS/ABI byte, which is noted once in libelf_loadhdrs() rather than re-derived; e_flags cannot be used for this, as an FDPIC object's are an unremarkable EABI version and testing them would reject every valid module. Text is taken from the media address plus the segment's own file offset -- the same arithmetic the ET_REL path already does with sh_offset -- and libelf_loadfile() does not read it. If the filesystem cannot show its media, the loader copies the text to RAM instead. The module then loses the shared text and the flash saving, but it runs. Obtaining that address needs two mechanisms, and they are not interchangeable. A compacting filesystem can move a file's blocks, so it hands out an address only with a pin that holds them still and expects the pin back; xipfs is the one in tree. A filesystem whose layout never changes has nothing to hold and answers FIOC_XIPBASE with a bare address; romfs and tmpfs are those. libelf_xipacquire() asks for the pin first, because a filesystem that needs one is not safe without it, and libelf_unload() gives it back. The loader asks for a pin only if it can hold one, or the pin would stay for ever. The pin is thus not specific to FDPIC. Any module that executes in place from a compacting filesystem takes one, and gives it back at unload. mmap() is not used, though both filesystems implement it. The mapping would be recorded against whichever task called the loader, while the release happens when the module's own task exits, which is a different group -- so the pin would outlive the module and the extent would never become movable again. Unloading has to change with placement: the existing path frees only textalloc because ET_DYN had a single allocation, which would leak an FDPIC object's data and free media the filesystem only lent us. Nothing here runs for a non-FDPIC object; every branch is behind the flag and the single-allocation path is untouched. Built and booted mps3-an547:picostest, which is CONFIG_ELF with CONFIG_PIC, with no change in behaviour. Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
43 lines
1.5 KiB
Text
43 lines
1.5 KiB
Text
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
#
|
|
|
|
config FS_XIPFS
|
|
bool "XIPFS contiguous execute-in-place file system"
|
|
default n
|
|
depends on !DISABLE_MOUNTPOINT && MTD
|
|
select FS_PIN
|
|
---help---
|
|
Enable support for XIPFS, a file system that stores each file as a
|
|
single physically contiguous, erase-block aligned extent on memory
|
|
mapped flash.
|
|
|
|
Because files are contiguous and the media is directly addressable,
|
|
XIPFS can return a real pointer into flash from mmap(), so a module
|
|
can be executed in place without its read-only text and rodata ever
|
|
being copied into RAM. This requires the underlying MTD driver to
|
|
implement the BIOC_XIPBASE ioctl.
|
|
|
|
Files are write once: a file is created at a known size, written
|
|
sequentially, closed, and is immutable thereafter until it is
|
|
deleted. Random writes, appends and growth are not supported.
|
|
|
|
Directories are supported. They are records in the same metadata
|
|
generation the files are, not objects in the data region, so an
|
|
empty one costs one entry out of the volume's fixed supply and no
|
|
flash blocks at all.
|
|
|
|
if FS_XIPFS
|
|
|
|
config FS_XIPFS_FAULT_INJECT
|
|
bool "XIPFS flash fault injection"
|
|
default n
|
|
---help---
|
|
Add a countdown to the XIPFS flash write and erase paths so that a
|
|
test can fail an arbitrary flash operation and then remount, which
|
|
models a power loss at that exact point.
|
|
|
|
This is a test-only facility. Do not enable it in production.
|
|
|
|
endif # FS_XIPFS
|