-
Notifications
You must be signed in to change notification settings - Fork 5
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 the yk-linkage llvm pass. #62
Conversation
I'm fine with this -- but I'm also starting to get a bit nervous about the quantity of things where we're subtly adding conditions above and beyond the normal. I think we should probably have a page in the docs along the lines of "yk details that might affect you" (not a good name, but hopefully you get the idea!) that documents these things. One day, we'll probably be grateful that there's a central record of these things. You could add such a page in this PR, and then flesh it out with the older quirky stuff we've done in another PR? |
I think it would be better as a separate PR, as this is the compiler repo. |
Good point! |
Would this page be the one to expand? I can probably think of lots of other things to put here. |
Yes, that might be something to build upon. I think we would, at least, need two sections: "how yk changes the build process" and "how yk changes the language/run-time". |
Now that Lukas' PRs are done, can I rebase this? |
I don't think it needs rebasing. bors r+ |
llvm/lib/Transforms/Yk/Linkage.cpp
Outdated
//===- Linkage.cpp - Ajdust linkage for the Yk JIT -----------------===// | ||
// | ||
// The JIT relies upon the use of `dlsym()` at runtime in order to lookup any | ||
// given function from its virtual addresses. For this to work the symbols for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: virtual address, not addresses
bors r- |
Canceled. |
Fixed typo. OK to squash? |
Please squash. |
The JIT relies upon the use of `dlsym()` at runtime in order to lookup any given function from its virtual address. For this to work the symbols for all functions must be in the dynamic symbol table. `yk-config` already provides the `--export-dynamic` flag in order to ensure that all *externally visible* symbols make it in to the dynamic symbol table, but that's not enough: functions marked for internal linkage (e.g. `static` functions in C) will be missed. This pass walks the functions of a module and flips any with internal linkage to external linkage. Note that whilst symbols with internal linkage can have the same name and be distinct, this is not so for symbols with external linkage. That's OK for us because Yk requires the use of LTO, and the LTO module merger will have already mangled the names for us so that symbol clashes can't occur.
b6ac65b
to
547f154
Compare
splat. |
Well isn't that lucky! |
bors r+ |
Build succeeded: |
Compiler side fix for ykjit/yk#647.
Depends on ykjit/yk#650 and #61.
See commit message for a detailed description of what this does.
Associated PRs for yk and yklua coming soon.
(I wanted to test the name mangling aspect of this, but the llvm test suite isn't geared up for multi-object tests. They defer such tests to another repo, which I don't really want to fork and maintain. We can rely on yk and interpreter tests)