There is a flaw regarding the resolution of a module's ModuleInfo?.
Linker presently searches for the resident ModuleInfo? for initalization, by way of the Module's getNamespace() method. For OMF modules, this is determined by the embedded file name for the module. The problem comes in when a developer compiles a module by using a full path - this allows the drive letter and extra directories to be folded into the namespace!
Proposed Solution:
Extend ExportSymbol? to incorporate a subtype for where the symbol originated from. This way, a symbol will provide six states:
- Local, unresolved (was: Extern)
- Local, resolved (was: Strong)
- Local, weak (was: Weak - before linker pass)
- External, unresolved (was: Extern)
- External, resolved (was: Strong)
- External, weak (was: Weak - sometimes after linker pass)
The last state, External + Weak, will likely never be used. The remaining five states can help reduce the ambiguity that arises from needing to identify which ModuleInfo? actually belongs to a given module. A module that includes multiple modules, will simply appear to have multiple Strong ModuleInfo?'s - this change will instead make one stand out as clearly "Local+Resolved" and the rest "External+Resolved".
