[8/10] binfmt/elf: Load FDPIC modules through the ELF loader

[casaroli]

depends-on: [/pull/20089 /pull/20130]

Summary

[5/10] #19942 places and binds an FDPIC object; [6/10] #20089 relocates it; [7/10] #20130 lets the firmware call back into it. This makes exec() of one work.

The task needs the module's data base in its PIC base register. binfmt builds a D-Space for any object with a GOT, taking the base from the .got address; an FDPIC object names it in DT_PLTGOT instead, which the loader has already translated. The two are the same idea reached by different routes, and both are what up_initial_state() installs.

Constructors are not binfmt's business. A module carries its own crt0, which walks .init_array on the task that runs the module and then calls main, so they run in the module's own context with its own data base. For a module arriving through dlopen(), libelf_insert() walks the array instead, entering each entry through fdpic_invoke(), because a descriptor resolved on the calling task carries the wrong base.

The read-only segment of a module that executes in place is held by a filesystem pin. The load takes it, and the module owns it from the point where nothing can fail any more; it is given back when the task exits. The pin is held through a reference to the file rather than a descriptor, because the descriptor belongs to the task that called the loader while the release happens on another.

libelf_remove() and libelf_uninit() give back what an FDPIC module holds: the pin, and the writable segment. The read-only one is media rather than an allocation and must not be freed.

Impact

Behind CONFIG_FDPIC, which defaults off. With it off, binfmt is what it was.

Testing

mps3-an547:picostest builds with CONFIG_FDPIC off and on, standing alone on master.

tools/checkpatch.sh -c -u -m -g passes.

Draft

Draft until [6/10] and [7/10] are reviewed, since this is the point where they first have to work together.

[github-actions]

MemBrowse Memory Report

s698pm-dkit

• Code: .text +272 B (+0.1%, 367,824 B)
  No memory changes detected for:
• arduino-mega2560
• esp32-devkitc
• hifive1-revb
• mirtoo
• qemu-armv8a
• qemu-intel64
• rx65n-rsk2mb
• stm32-nucleo-f103rb