-
Notifications
You must be signed in to change notification settings - Fork 38
Store sharer and eraser in function prefix #768
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
base: master
Are you sure you want to change the base?
Conversation
How does this lead to an additional indirection? I would have assumed it would just be an additional offset computation. |
Previously it was: Now it is: |
Hmm... I expected it to be
but maybe my mental model of how LLVM works is just off here, or you implemented a different variant than I had in mind (where the sharers and erasers are always placed at a particular offset of the return address in code). |
I didn't see an easy way to place functions relative to each other. |
ok, then the additional indirection makes sense, thanks for the explanation |
Is there a way to make the linker happy? |
6e6ef9f
to
c08e1a9
Compare
This should be ready now. It turns out the linker doesn't like pie :) |
Are the benchmark results from above still up to date? |
What are the most important down sides in your opinion of giving up position independence? |
I don't know really know about the downsides. According to claude, there are some security vulnerabilities with position dependence. |
Without
|
This reduces the size of frame headers for faster PushFrame/Return.
Non-linear handlers get slower though, because now there is an additional indirection for sharers/erasers.