Rename toolchain target triple to solana specific name

[dmakarov]

Problem

The current target triple used by the compiler toolchain is bpfel-unknown-unknown. As we move further from the original BPF architecture in various ways, we should distinguish our toolchain by using a Solana-specific target triple.

Proposed Solution

The Solana-specific flavor of the original BPF is called Solana Bytecode Format or SBF. The new target triple used by the compiler toolchain will be sbf-solana-solana, where sbf is the architecture, solana is the vendor, and none is the operating system.

In this issue, we'll collect information about everything in the existing Solana ecosystem that may be affected by changing the target triple.

Things that should to be changed first to enable SBFv2

• New SBF target triple
• New SBF backend in llvm repo. #27579
• New machine definition in the ELF header (no longer Machine: Linux BPF). See detail in above task.
• Update rust target_arch check to use sbf in addition to bpf
• build-bpf no longer makes sense, create build-sbf and alias build-bpf
• Rename Rust's os mod from "BPF" to "SBP"
• bpf-tools renamed

The rest of the things that need to be changed:

• Update Solana docs that specify "BPF"
• Code comments that highlight the change from "BPF" to "SBF", examples are sdk/program/src/bpf_loader.rs and the like
• bpf_loader program name changed to sbf_loader program
• C sdk (sdk/bpf) renamed as well as update the C headers to SBF
• Update /scripts and /ci to refer to SBF instead of BPF
• Rename program arguments, example: no-bpf-jit
• rbpf repo name changed, references to "BPF" changed to "SBF", and verbiage describing the lineage of BPF to SPF for historical context
• rbpf-cli renamed
• New program ABI should use "SBF" naming from the get-go (for example for its program id)

The above list is all the places that need to change. Please add any missing ones. The list is long and some will be much harder than others but they don't all have to be done at once.

[dmakarov]

@jackcmay @mvines @garious @Lichtso

[Lichtso]

We might want to rename our crate https://lib.rs/crates/solana_rbpf to match the new architecture name.
The "R" for Rust in front of BPF is misleading anyway.

Also, now that we are explicitly talking about our ABI, wouldn't that make solana an OS in this context?

[jackcmay]

yes, I think solana becomes the "OS"

[dmakarov]

Should I use solana both for vendor and OS in the triple, or we can come up with another name for OS?

[jackcmay]

I updated the issue description to include a list of all the places I could think of that need to be changes. Please add any others I might have missed

[Lichtso]

Do we still need the special BPF instructions for loading from the input section?
I mean the 8 instructions which load from an offset or register plus offset and only work for the input section.
They might have been useful for network packet filtering in the past.
But, in the new ABI the input section won't be special anymore / might as well not exist.

Also, we might want to collect all differences of sbf from bpf in one place.

[jackcmay]

I assume you are talking about the ones described in section 9.7.4.5 here:
9.7.4.5 Load instructions for socket filters
Related to direct packet access referred to here: https://www.kernel.org/doc/Documentation/networking/filter.txt in section "Direct packet access"

Yes I think we should get rid of those.

As for an SBF spec (including differences from BPF) I'd like to see something simple and clear like this:
https://github.com/iovisor/bpf-docs/blob/master/eBPF.md

[dmakarov]

I added a task to remove the fixed frame size restriction as discussed in #13391.

[dmakarov]

For now I'm not adding a new SBF backend, but reusing the existing BPF backend. I hope to keep it this way to make it easier to bring in new changes from the upstream, while maintaining SBF customizations isolated in the original BPF backend.

[Lichtso]

Another wish for SBF: Restrict the callx jump targets to only allow known symbols (e.g. registered functions in the ELF).
Because currently a dynamic jump can enter a loop in-mid without going through the entry.
And that prevents important optimizations like the hoisting of address translation out of loops.

[jackcmay]

Another wish for SBF: Restrict the callx jump targets to only allow known symbols (e.g. registered functions in the ELF). Because currently, a dynamic jump can enter a loop in-mid without going through the entry. And that prevents important optimizations like the hoisting of address translation out of loops.

Architectural changes are being captured here in #20323, I've added this one.

[dmakarov]

anza-xyz/llvm-project#19
anza-xyz/llvm-project#20

The above changes make clang -target sbf work the same as clang -target bpf -march=bpfel+solana. At the moment the BPF backend is used. If later we add SBF backend the command line interface will not change, so now we can proceed with making changes in solana-labs/solana to use the new SBF target.