The Design and Implementation of the Anykernel and Rump Kernels

127
The bootstrap procedure iterates over all of the modinfo structures. This approach
is not directly applicable to a dynamically linked environment because the dynamic
linker cannot generate a combined section like static linking can — consider e.g. how
loading and unloading would affect the section contents at runtime. Still we, need a
mechanism for locating driver init routines when the rump kernel is bootstrapped.
This task of locating the init routines is done by the rumpuser_dl_bootstrap()
hypercall. It iterates over all the dynamic shared objects present and gathers the
contents of all the modules sections individually.
A related problem we discovered was the GNU linker changing its behavior in generating
the __start_section and __end_section symbols. Older versions generated
them unconditionally. In newer versions they are generated only if they are referenced
at link time (the “PROVIDE” mechanism). Since individual components do
not use these symbols, they do not get generated when the components are linked as
shared libraries. To address this regression, we created the component linker script
sys/rump/ldscript.rump which forces the generation of the symbols in shared
library components and restores desired behavior.
3.8.2 Modules: Loading and Linking
Runtime loading and linking in a rump kernel includes two distinct scenarios. First,
shared objects can be loaded and linked by the host’s dynamic linker. Second, static
objects can be loaded and linked by code in the rump kernel. We will discuss both
approaches next.