Dynamic linking concept: The transfer-vector (jump table) approach primarily enables access to which kind of external element across separately compiled modules?

Introduction / Context:
Some linkers and operating environments use transfer vectors (jump tables) to insulate call sites from the absolute addresses of external routines. Understanding what is accessed through these vectors clarifies binary compatibility and late binding strategies.

Given Data / Assumptions:

• Modules are compiled separately.
• Calls to external code may change address across versions.
• A level of indirection (transfer vector) is used for calls.

Concept / Approach:
A transfer vector is a table of branch/jump instructions or pointers that redirect calls to the current address of an external subroutine. Callers invoke the stub in the vector rather than a fixed absolute address. This enables updating libraries without recompiling dependents, provided the vector layout remains stable. Access to external data typically uses relocation or import address tables specific to data, not the same jump indirection intended for code calls.

Step-by-Step Solution:

Verification / Alternative check:
Historical systems (e.g., classic UNIX shared libraries, some embedded linkers) and modern import tables use similar indirection for functions.

Why Other Options Are Wrong:
External data segments / data in other procedures: typically accessed via relocated data pointers or GOT/IAT entries distinct from function jump vectors. All of the above: over-generalizes the transfer vector’s primary purpose.

Common Pitfalls:
Assuming a single mechanism handles both code and data uniformly; conflating PLT/GOT roles in modern ELF/PE formats.

Final Answer:
External subroutines