A module that names a shared library in DT_NEEDED now gets it loaded and
its imports bound against it, rather than being refused.
libelf_insert() does the loading, which is what dlopen() calls anyway: the
library lands in the module registry like anything else, its exports come
back through libelf_getsymbol() -- the same call dlsym() uses -- and a
library named by two modules is loaded once. A bare name is looked for
along LD_LIBRARY_PATH, where dlopen() looks for it. Undefined symbols
resolve against the globally registered symbols first, then the modules
this one depends on, then the table exec() supplied. Nothing here calls
into dlfcn, because this loader is also the kernel's module loader, which
has none.
Each library becomes one of the module's dependencies[], and the dependency
holds it in place of the reference libelf_insert() took. So a library
loaded only for DT_NEEDED is kept by the modules that depend on it, and
libelf_undepend() unloads it with the last of them; one that dlopen() or
insmod also opened stays until that reference goes too.
CONFIG_LIBC_ELF_MAXDEPEND bounds how many libraries a module may name,
which is what it already meant.
Six things had to be fixed to make it work, none of which a build shows.
reldata was a file-scope global. Loading a library from inside
libelf_relocatedyn() makes that function reentrant, so the nested load
overwrote the outer one's relocation offsets and the module resumed binding
with the library's DT_REL. It is now per call.
A cross-object call needs the callee's data base, not the caller's. A
symbol resolved from an FDPIC library comes back as a descriptor, and
R_ARM_FUNCDESC_VALUE was treating it as a code address and pairing it with
the importing module's GOT. It now copies both words, so the library runs
with its own.
An object with no imports has no PLT and so no DT_PLTGOT, but it still has
a GOT and still has to be entered with it. Without the fallback its
descriptors carried a data base of zero and the library read its globals
through a null pointer.
R_ARM_FUNCDESC, a pointer to a descriptor, wrapped a library's descriptor
in a second one. It now stores the library's descriptor as it is.
The flag that says a resolved value is a descriptor was set only for an
import and never cleared, so the next relocation against a symbol of the
module itself took that symbol for a descriptor too. It is cleared there.
libelf_symname() was static, and reading a DT_NEEDED name needs it.
A module with DT_NEEDED is refused where CONFIG_LIBC_ELF_MAXDEPEND is zero,
since that is where the dependency logic is compiled out.
A DT_NEEDED library is one shared instance, its data included, because the
loader returns the object already in the registry. A module started with
exec() is different: that path loads the module afresh each time, so two
running instances have separate data while sharing one copy of the text.
Built for mps3-an547:picostest with CONFIG_FDPIC both ways. Run on
mps2-an500:xipfs under QEMU: fdpicxip solib loads libcounter.so by name out
of DT_NEEDED, two instances share one pinned copy of its text, and the
library is unloaded, and its pin given back, when the second one exits. A
library also opened with dlopen() stays loaded after its DT_NEEDED user
exits, and dlclose() unloads it.
With CONFIG_ARCH_ADDRENV the program runs in its own address space, which
a library libelf_insert() loads cannot reach, so DT_NEEDED is refused
there as before.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
An architecture that sets CONFIG_ARCH_USE_DATA_HEAP gives a loaded module
its data from up_dataheap_memalign(), because the ordinary heap is not where
that data belongs there. The ELF loader honours it for every object but an
FDPIC one: an FDPIC object places its writable segment on its own, and that
allocation, and the two places that free it, still use lib_memalign() and
lib_free(). Its text already comes from the text heap.
So an FDPIC module's data goes to the data heap too, and back to it when the
module is unloaded or removed.
On mps3-an547, which sets both heaps, fdpicxip loaded the data of its two
instances at 0x1007220 and 0x104e480, in the ordinary heap. With this change
they are at 0x21000000 and 0x21000180, in the SRAM2 data heap, and both
instances run. In a protected build the difference matters: there the
ordinary heap is kernel memory, and the module takes a data access violation
on its first access to its data.
Assisted-by: Claude Code:claude-opus-5-5
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
exec() of an FDPIC module now works. The loader already places such an
object and binds it; what was missing is everything binfmt has to carry
across from the load to the running task.
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
section address; an FDPIC object names it in DT_PLTGOT instead, which the
loader has already translated, so 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 and with its own data base.
For a module that arrives through dlopen(), libelf_insert() walks the array
instead, and it enters 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 that runs
the module 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 and the release happens on another one.
libelf_remove() and libelf_uninit() give back what an FDPIC module holds:
the pin, and the writable segment, while the read-only one is media rather
than an allocation and must not be freed.
Built for mps3-an547:picostest with CONFIG_FDPIC both ways.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
libelf_uninit() only called libelf_freesymtab() when the module had an
uninitializer. But the exported symbol table is built by
libelf_insertsymtab() for every loaded module, and nothing in the tree
sets modinfo.uninitializer anymore: modules have registered their
teardown through .fini_array since a9cb28cd23. The condition is
therefore always false and every rmmod()/dlclose() leaks the exports
array together with the strdup-ed symbol names.
Call libelf_freesymtab() unconditionally, and clear the exports
pointers next to it instead of under a vestigial procfs guard that
dates back to the removed module initializer field.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
libelf_remove() takes the module out of the registry but never frees
the registry entry, so every successful rmmod()/dlclose() leaks
sizeof(struct module_s), the name included. The lib_free() call was
dropped by e9550783d3 when the removal path was reworked.
Free the entry after the registry lock is released.
Assisted-by: OpenAI Codex
Signed-off-by: yushuailong <yyyusl@qq.com>
dlopen() of a library that is already loaded fails. libelf_insert()
rejects a name that is already in the module registry with EEXIST, and
dlinsert() passes that straight out, so the second caller gets NULL.
POSIX says dlopen() shall return a handle to the object, and there is no
way today for two modules to hold the same library at once -- which is
what a shared library is for.
So dlopen() now takes another reference on a library that is already
there, and dlclose() only tears it down when the last handle goes. The
count lives in the dlfcn layer rather than in libelf_insert() so that
insmod keeps its own behaviour: a second insmod of the same name still
fails with EEXIST, which is right for a kernel module.
The module name is what makes any of this possible, and a PROTECTED build
did not have one. Names were defined for CONFIG_BUILD_FLAT or the kernel
side of a split build, on the reasoning that only the kernel needed them,
which predates dlopen() being usable from user space. Without a name the
user-space copy of libelf cannot recognise a second open of a library,
cannot count opens, and cannot make dlclose() mean anything -- two
dlopen()s there produce two independent copies of the library and lose
track of the first. Names are therefore defined wherever CONFIG_LIBC_DLFCN
is, which costs NAME_MAX per loaded module in that configuration.
The path no longer has to be copied either. The module name is the
basename of the file and libelf_insert() takes it as a const string, so
dlinsert() finds it with strrchr() instead of handing a writable
duplicate of the whole path to basename().
BUILD_KERNEL is deliberately untouched. dlopen() returns NULL there
unconditionally: dlinsert() is a stub, because sharing a library between
processes with separate address spaces needs the text in a shared region
and the data per process at a matching virtual address, which is a
different problem from this one.
Built for mps3-an547:picostest with and without CONFIG_LIBC_DLFCN, and
for stm32f4discovery:kostest, a PROTECTED configuration, with it enabled.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>
debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
Renaming "modlib" to "libelf" is more in line with the implementation content,
which makes it easier for individual developers to understand the capabilities of this module.
CONFIG_LIBC_MODLIB -> CONFIG_LIBC_ELF
Signed-off-by: chao an <anchao.archer@bytedance.com>
2025-04-11 09:43:22 +08:00
Renamed from libs/libc/modlib/modlib_remove.c (Browse further)
