casaroli opened a new pull request, #20131: URL: https://github.com/apache/nuttx/pull/20131
depends-on: [apache/nuttx/pull/20089 apache/nuttx/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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
