Dynamic stack frame size support #274
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alessandrod
force-pushed
the
dynamic-stack
branch
7 times, most recently
from
70d0e1f
to
01d13ed
Compare
alessandrod
changed the title
alessandrod
force-pushed
the
dynamic-stack
branch
3 times, most recently
from
5ae3815
to
87b6f05
Compare
alessandrod
force-pushed
the
dynamic-stack
branch
from
0f50258
to
87b6f05
Compare
dmakarov
approved these changes
Mar 17, 2022
This change implements dynamic stack frames when config.dynamic_stack_frames is set to true. When dynamic_stack_frames=true, r11 is exposed as the stack pointer. The stack is fully descending, so `sub r11, N` can be used to grow it, and `add r11, N` to shrink it. Those are the only operations allowed on r11, which are special cased by the interpreter and jit to resize the stack. No other operations are allowed on the stack register.
alessandrod
force-pushed
the
dynamic-stack
branch
2 times, most recently
from
6f6adac
to
8a7152f
Compare
18 tasks
10 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements dynamic stack frames, which can be enabled setting
config.dynamic_stack_frames = true.When using dynamic stack frames, r11 is exposed as the stack pointer. The stack is fully descending, so
sub r11, Ncan be used to grow it, andadd r11, Nto shrink it. Those instructions are special cased by the interpreter and jit to resize the stack. No other operations are allowed on the stack register.The stack pointer is allowed to overflow. In real programs, it's almost impossible to overflow since programs are metered and we enforce a max call depth. In fringe programs that (intentionally?) do overflow,
EbpfError::AccessViolationis returned byMemoryRegion::map()once the overflown stack pointer is accessed. I opted for this since I think it's the best tradeoff for jitted programs (the BPF stack is separate from the jit stack so overflows won't mess with the jit), but happy to do explicit overflow checking if anyone feels strongly about this (although I'm not sure what the benefit would be).At the moment
config.max_call_depthis still enforced regardless of whether fixed or dynamic frames are in use, we might want to change that.Dynamic frames are turned on if the input ELF is flagged as
EF_SBF_V2(see anza-xyz/llvm-project#26) andconfig.dynamic_stack_frames=true. Which means that a feature gate can be used in the monorepo to setdynamic_stack_frames=falseto disable the feature entirely.I've added tests which should cover all changes, and the rustc
library/coretests pass with both fixed and dynamic frames.