Dynamic Linking

This is the core mechanism where the host's dynamic linker/loader matches undefined references in the plugin's code (symbols) with their actual memory addresses. The process involves:

• Name Mangling: The linker must understand compiler-generated symbol names to find the correct function or variable.
• Relocation: After loading the plugin into a memory address, absolute and relative references within its code must be adjusted (relocated) to point to the correct final addresses.
• Lazy Binding: An optimization where symbol resolution is deferred until the first time a function is actually called, speeding up initial load time.

The physical act of mapping the plugin's compiled binary (e.g., a .so file on Linux, .dll on Windows, .dylib on macOS) from disk into the host process's virtual memory space. Key steps include:

• Memory Mapping: The operating system maps the library file into the process address space, often using copy-on-write for efficiency.
• Segment Alignment: Code (.text) and data (.data, .bss) segments are placed in memory pages with appropriate permissions (execute, read, write).
• Dependency Loading: The linker recursively loads all other shared libraries that the plugin depends on, building a complete dependency graph.

These are critical data structures used in the Executable and Linkable Format (ELF) common on Unix-like systems to enable position-independent code and lazy binding.

• Global Offset Table (GOT): A table of pointers that holds absolute addresses of global variables and static data. The linker fills this in after loading.
• Procedure Linkage Table (PLT): A table of stub functions. The first call to a function jumps to the PLT entry, which then reads the resolved address from the GOT and jumps to it. This enables the lazy binding optimization.

Within an ELF or PE (Windows Portable Executable) file, a special section (.dynamic) contains an array of tags that serve as instructions for the dynamic linker. This metadata is essential for runtime linking.

• Needed Libraries: Tags (e.g., DT_NEEDED) list the names of required shared library dependencies.
• Symbol Tables: Pointers to the dynamic symbol table (.dynsym) and string table (.dynstr) used for symbol resolution.
• Relocation Tables: Pointers to relocation sections (.rela.dyn, .rela.plt) that tell the linker which addresses need adjustment.
• Init/Fin Arrays: Pointers to constructor (DT_INIT_ARRAY) and destructor (DT_FINI_ARRAY) functions that run on load and unload.

The programmatic interface exposed to the host application for manual control over dynamic linking. The POSIX standard defines this API.

• dlopen(): Loads a shared library, resolves its dependencies, and returns a handle. Flags control behavior (e.g., RTLD_LAZY for lazy binding, RTLD_NOW for immediate resolution).
• dlsym(): Takes a library handle and a symbol name (e.g., "plugin_initialize") and returns the memory address of that symbol.
• dlclose(): Decrements the reference count on a library. The library is unloaded from memory when its count reaches zero.
• dlerror(): Retrieves a human-readable error message if any of the above operations fail.

Mechanisms to manage compatibility and control which symbols are exposed for linking.

• Symbol Versioning: Allows a single shared library to provide multiple implementations of the same function, tagged with version strings (e.g., memcpy@GLIBC_2.2.5). The linker binds to the version required by the plugin.
• Default/Hidden Visibility: Compiler attributes (e.g., __attribute__((visibility("default"))) in GCC) control which symbols are exported in the dynamic symbol table. Hiding non-API symbols reduces namespace pollution and improves loading performance.
• Linker Scripts and Version Maps: Provide fine-grained control over symbol export and versioning, defining which symbols are available under which version tags.

A software design pattern where a core host application provides a stable framework, and its functionality is extended through modular, independently developed components called plugins. The architecture defines the contracts and lifecycle for these extensions.

• Core Principles: Separation of concerns, modularity, and extensibility.
• Host Responsibilities: Provides extension points, manages the plugin lifecycle, and handles dependency injection.
• Plugin Responsibilities: Implements specific interfaces, declares dependencies, and operates within the host's security sandbox.

A metadata file (JSON/YAML) that declares a plugin's identity and requirements to the host system. It acts as a machine-readable contract for discovery and compatibility.

• Typical Contents: Plugin name, unique ID, version (using Semantic Versioning), author, description, entry point, and required API contract version.
• Capability Declaration: Lists system permissions or resources the plugin needs (e.g., network_access, file_write).
• Dependency Mapping: Specifies other plugins or library versions it requires, enabling the host to build a plugin dependency graph for correct load order.

The capability of a host system to replace a running plugin's compiled code with a new version without restarting the host application or other plugins. This is enabled by dynamic linking and sophisticated memory management.

• Developer Workflow: Critical for rapid iteration, allowing developers to see code changes live.
• Technical Challenge: Requires safely unloading the old module, handling state migration, and updating function pointers in the symbol table.
• Risk Management: Often coupled with sandboxing to contain crashes and graceful degradation to maintain system stability if the new plugin fails.

A security mechanism that isolates a plugin's execution environment, restricting its access to system resources, memory, and other plugins. It is a critical counterpart to dynamic linking's power.

• Isolation Techniques: Uses OS-level process isolation, language runtime boundaries (e.g., WebAssembly), or system call interception.
• Capability Model: Plugins request specific capabilities (e.g., 'networking', 'filesystem:/var/log/'); the host grants limited, auditable permissions.
• Purpose: Prevents a faulty or malicious plugin from crashing the host or accessing sensitive data, enabling secure enclave execution for AI tool calls.

Design patterns where a plugin's required services and configurations are provided ('injected') by the host framework, which also manages the plugin's lifecycle (Inversion of Control).

• Decoupling: The plugin does not instantiate its dependencies; it declares what it needs via interfaces.
• Host Responsibility: The host's IoC container resolves and wires up these dependencies at runtime.
• Benefit for Plugins: Simplifies plugin code, enables testing with mock dependencies, and allows the host to manage shared resources like database connections or configuration.

The formal specification of interfaces between host and plugins, governed by versioning rules to ensure compatibility.

• API Contract: Defined via Interface Definition Language (IDL), abstract classes, or protocol buffers. It dictates the methods, data types, and expected behaviors.
• Semantic Versioning (SemVer): A versioning scheme (MAJOR.MINOR.PATCH) critical for managing evolution.
  • MAJOR: Breaking changes to the API contract.
  • MINOR: New, backwards-compatible functionality.
  • PATCH: Backwards-compatible bug fixes.
• Host Policy: Uses the plugin manifest to enforce version compatibility, preventing runtime linking errors.