Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a weak/strong flag to RuntimeDyld's symbol table. #23027

Closed
lhames opened this issue Feb 21, 2015 · 3 comments
Closed

Add a weak/strong flag to RuntimeDyld's symbol table. #23027

lhames opened this issue Feb 21, 2015 · 3 comments
Labels
bugzilla Issues migrated from bugzilla

Comments

@lhames
Copy link
Contributor

lhames commented Feb 21, 2015

Bugzilla Link 22653
Resolution FIXED
Resolved on Apr 15, 2015 16:33
Version trunk
OS All
CC @dwblaikie,@echristo,@Keno

Extended Description

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.

@echristo
Copy link
Contributor

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?

@lhames
Copy link
Contributor Author

lhames commented Feb 25, 2015

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.

@lhames
Copy link
Contributor Author

lhames commented Apr 15, 2015

This was fixed by r231724.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

2 participants