-
Notifications
You must be signed in to change notification settings - Fork 39
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
Dynamic stack frame size support #26
Dynamic stack frame size support #26
Conversation
d2098c7
to
f44f95c
Compare
I just realized that this needs to be made opt-in for the foreseeable future, otherwise we can't do a new toolchain release until the rbpf change reaches all the way to MB. Might be time to finally have |
I'm going to release bpf-tools with rust 1.59.0 soon. That probably still can be with the old fixed stack. Later these changes can be applied on top of solana-1.59.0 branch. Yes, we can rename cargo-build-bpf to cargo-build-sbf at that point. @jackcmay What do you think? I'm not sure why we need to wait for rbpf changes to be on MB and not on master branch of solana? Once solana-labs/solana starts using the dynamic stack rbpf, we have to release the updated compiler too. |
Yay 🎉
I think we'll have to keep both for the foreseeable future. There's plenty of documentation out there that refers to
Yes but dynamic frames will be feature gated and off to start with in devnet. Then eventually they'll be turned on, make it to testnet and MB. In the meantime, people need to be able to compile and deploy their programs, and we probably want them to be able to do that with the latest toolchain, without having to tell them "if you want to deploy to MB, you need to use toolchain version X". |
Can the prologue/epilogue etc changes be guarded by a command line option (like a feature maybe?) that is disabled by default. Later we can enable it by default or remove the guards. |
Yep that's what I meant with opt in, putting it behind a feature now |
Yeah, gotta featurize these changes and continue to support the existing BPF architecture. Are there other breaking changes we wanted to get into SBF that we might want to put in at the same time, or do you guys think its better to increment the SBF version each time we introduce one? |
We've already removed support fot ldabs* and ldind* in LLVM and that change made it to the last bpf-tools release I think. The corresponding rbpf change is feature gated. Since our API crates never supported/never led to the emission of ldabs* and ldind* anyway, practically speaking I don't think that was a breaking change in the compiler. Dynamic stacks are the only big breaking change I think. When we do the @Lichtso is there anything else you think should go in with this? |
We also had adding support for signed division on the list for SBFv2, do we want to roll that into this change from BPF to SBF as well? |
It looks like signed division was already enabled a while ago via intrinsics. I'm assuming you mean undo that, and add a a new instruction so we can jit it? |
Ok I've pushed an extra commit that makes this opt-in (I'll squash before merging). The way to opt-in is:
Next, I'm going to make |
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
lld/ELF/Arch/BPF.cpp
Outdated
@@ -30,7 +30,9 @@ class BPF final : public TargetInfo { | |||
const uint8_t *loc) const override; | |||
RelType getDynRel(RelType type) const override; | |||
int64_t getImplicitAddend(const uint8_t *buf, RelType type) const override; | |||
void relocate(uint8_t *loc, const Relocation &rel, uint64_t val) const override; |
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.
If there is a bunch of pure formatting changes it's nice to pull those into a separate pr
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.
Removed
dbgs() << " "; | ||
DL.print(dbgs()); | ||
} | ||
dbgs() << " Function " << MF.getFunction().getName() << " Stack offset of " << -Offset |
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.
Don't we want to keep displaying this message for fixed solana stack frames?
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.
Yup nice catch, fixed
MachineBasicBlock::iterator &MBBI, | ||
unsigned int Opcode) { | ||
MachineFrameInfo &MFI = MF.getFrameInfo(); | ||
int NumBytes = (int)MFI.getStackSize(); |
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.
Is the total stack size known to llvm or does it allow overflow expecting the runtime to catch it?
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.
It can't be known statically and the runtime needs to handle overflows anyway for hand rolled code
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.
Looks good, just a couple of nits/questions
9597ca3
to
8110fd3
Compare
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
--arch allows selecting the target SBF version. See anza-xyz/llvm-project#26.
LLVM side of solana-labs/rbpf#274. Based on initial work from @dmakarov.
This PR does two things:
r11
as the stack pointer in function prologues/epilogues.e_flags
field on ELF headers toEF_SBF_V2
(0x20
).rbpf
looks ate_flags
and if it'sEF_SBF_V2
it turns on dynamic frames (if enabled in the vm).I opted to use
e_flags
instead of OSABI/ABIVERSION since it's what all other tagets do (except AMDGPU). The idea is that if we need to bump ABI again, we'd useEF_SBF_V2_1 = 0x21
etc.