RuntimeDyld's symbol table doesn't currently distinguish between weak and strong symbols. All symbols are currently treated as strong, leading to spurious symbol clashes. We should add a 'weak' flag to RuntimeDyld's symbol table. The symbol visibility support introduced in r226341 provides a template for how to approach this, but rather than add more methods (along the lines of getExportedSymbolLoadAddress), we should change RuntimeDyld's getSymbolAddress methods to return a RTDyldSymbol object that provides access to both the 'weak' flag and visibility.
What sort of thing are you seeing? Previously the idea was that anything in the executable was treated as strong and would just be a symbol lookup. Are we trying to override symbols in the executable with jitted symbols? How would that work in practice?
Hi Eric, Nothing that fancy. This is for the situation where the user adds both weak and strong definitions to the JIT. In that case we want to resolve to the strong version within the JIT. Usually we'll want to handle this by stripping duplicate definitions in an IR-layer, but you can also add raw objects to the JIT, and (for now) there's no way to strip duplicate functions out of those. As a concrete-ish example: If you have a JIT-runtime you'd want to precompile it to an object (since it doesn't change between runs), but you may want JIT'd user code to be able to override these (or you may want to be able to supply your own strong overrides for debugging). In this case you could mark the overridable runtime functions as weak. Keno - It sounds like you've got a real world use case for this too. It'd be interesting to hear where it's coming up for you. - Lang.
This was fixed by r231724.