Skip to content
This repository has been archived by the owner on Mar 20, 2024. It is now read-only.

Translate from stackless bytecode and test inside rbpf #24

Merged
merged 5 commits into from
Feb 3, 2023

Conversation

brson
Copy link
Collaborator

@brson brson commented Jan 30, 2023

This primarily does two things: add a translation from the "Move model" and its "stackless bytecode" to LLVM; and add an rbpf-based test harness.

The implementation can just do a few scalar ops, compile and link, and run inside rbpf, but the path is open to implement most typical codegen features that aren't specific to Move.

Translation from stackless bytecode is so far straightforward: it provides a list of local variables and a list of instructions that operate on them. In LLVM these locals are translated as allocas, and the move instructions as load/op/store sequences. LLVM's mem2reg pass should optimize these fine.

Running the rbpf-tests requires an installation of bpf-tools. Instructions for setting this up are in the readme.

There is a lot of obvious follow-on work to do and I'll file issues about them.

It may be easier to review individual patches than the entire patch at once.

Things to note:

  • this makes one change to the move codebase, making script_into_module public
  • this introduces the llvm-extra-sys crate to hold C++ LLVM glue code. At present it is only used to add the 'NoReturn' attribute to move_rt_abort. I can see no way to do this via the C API. Whether the noreturn attribute matters much I am not clear: calls to this function are also followed by an 'unreachable' instruction.
  • the rbpf test harness uses my own fork of rbpf which contains a hack to get the linked dylibs to validate: the text segment of the dylibs starts at an address higher than rbpf expects. It's probably just a matter of using the correct linker flags. We'll be able to unfork it.
  • this doesn't attempt to encode any debug info for now

cc #21
cc #22
cc #23

@brson brson requested a review from ksolana January 30, 2023 22:51
Copy link
Collaborator

@ksolana ksolana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this.

@ksolana ksolana merged commit b1ed8bd into anza-xyz:llvm-sys Feb 3, 2023
LLVMInitializeBPFTargetInfo();
LLVMInitializeBPFTarget();
LLVMInitializeBPFTargetMC();
LLVMInitializeBPFAsmPrinter();
Copy link

@nvjle nvjle Feb 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It probably does not matter today, but we may soon want to start using the new SBF back-end here (LLVMInitializeSBF*) instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. At the moment I am using the old BPF target definitions, not sure how ready SBF2 is, but I expect to switch to SBF at some point since if the move backend is ever finished it will be well after SBF2 is deployed.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, the default back-end today is the SBF back-end. That is, I believe all of our ordinary production scripts should be using sbf-solana-solana. So at the moment, target sbf-solana-solana generates roughly the same code as target bpfel-unknown-unknown with +solana. The ELF e_machine values differ, of course (EM_BPF vs EM_SBF).

This new back-end is part of the overall transition away from BPF to SBF in our tools, scripts, etc (solana-labs/solana#19113). If by SBF2 you mean SBFv2 (solana-labs/solana#20323), some of that can be considered orthogonal work (enhancing/modifying the ISA, etc) to happen later.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarifications. I wasn't not sure what the distinction between sbfv1 and sbfv2 I had seen in the code were, nor that the tooling had already switched to the sbf target.

I filed an issue #33

impl Target {
fn triple(&self) -> &'static str {
match self {
Target::Solana => "bpfel-unknown-unknown",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If/when llvm.rs changes to SBF back-end, this should become sbf-solana-solana.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants