weizhiao/Relink

Background ELF dynamic executables may contain DT_PREINIT_ARRAY and DT_PREINIT_ARRAYSZ entries. These point to functions that should run before regular initialization (DT_INIT / DT_INIT_ARRAY) for executables. Problem Relink currently parses and exposes regular init/fini metadata, but does not handle pre-initialization arrays. This means dynamically linked executables that rely on DT_PREINIT_ARRAY can miss required early initialization work. DT_PREINIT_ARRAY is only meaningful for executables; shared objects should not use it. Proposal Add explicit support for DT_PREINIT_ARRAY while preserving the existing init/fini lifecycle model. Suggested shape: Add DT_PREINIT_ARRAY and DT_PREINIT_ARRAYSZ parsing to dynamic metadata. Store the preinit array as an optional &'static [fn()] or equivalent lifecycle input. Execute preinit callbacks before DT_INIT and DT_INIT_ARRAY for dynamic executables. Ignore or reject preinit arrays for shared objects, depending on the loader policy chosen. Add tes

Relink currently has Linux libc, Linux syscall, Windows, and bare-metal-style mmap backends. I would like to figure out what a good BSD support story should look like before committing to a specific implementation. The current Unix/libc path is not really a portable Unix contract. It assumes mmap and madvise values can be passed through as-is, but those details differ across BSD systems. Page size handling, file-backed mappings, executable mappings, and huge-page behavior may also need platform-specific treatment. It would be helpful to hear from people using or interested in FreeBSD, DragonFly, NetBSD, or OpenBSD. Open questions: Which BSD target should come first? What should the first pass support: compile-only, memory-input loading, file-backed loading, runtime tests, or CI? Are the current Mmap, MapFlags, and MadviseAdvice abstractions enough, or should this become more capability-oriented? How should Linux-only options, such as huge-page flags, behave on BSD? What CI or runner s

Background LinkContext is an important Relink concept: each context is an isolated module repository, dependency graph, and symbol scope. Separate contexts do not automatically share loaded modules; sharing must be explicit through APIs such as snapshot() or extend(). The README mentions this capability, but there is no runnable example for it yet. Task Add a new example, for example: examples/link_context_isolation.rs The example should show: Creating two independent LinkContexts Loading a module into the first context Verifying that the second context does not automatically see that module Optionally showing how snapshot() or extend() can explicitly share loaded state Acceptance Criteria cargo run --example link_context_isolation works The README examples table references the new example The example clearly demonstrates “isolated by default, shared only explicitly”