[BUG] Silent opcode offset truncation

[alnoki]

@deanmlittle @clairechingching @bidhan-a

2026-01-14 EDIT: Per #97 (comment), correct description offset type to i16, and add a section about LLVM

Snippet

    stxdw [r3 + 100000000000000000], r4

Description

This assembles, even though the SBPF spec stipulates u16 i16 offsets. The culprit appears to be silent truncation via the internal casting process, e.g. in this case the offset gets silently cast to 0x0

Why this is a problem

Once an instruction requires more than 6 3 accounts, hard-coded offsets relative to the start of the input buffer (r1) will exceed U16_MAX = 65535 I16_MAX = 32_767 even if all accounts have no data. This is due to the minimum 10240 bytes of account data reallocation padding.

If an sbpf user prepares .equ-style offsets using a Rust script or similar, they'll get no feedback about the offsets getting truncated, and will experience undefined behavior in the resultant program.

Regarding LLVM

If LLVM silently truncates, it is implementing a massive footgun that will lead to undefined behavior that can easily be prevented. Absent any strong argument to the contrary, I submit that with regard to silent offset truncation LLVM is itself broken and should be fixed. Assuming this, there is no merit to feature parity for the sake of feature parity if it means copying a broken implementation

Expected behavior

Some kind of error message that says offsets must fit in a u16 offsets must fit in an i16 and panics the assembler

[deanmlittle]

As stupid as it this, this actually matches the behavior of LLVM. It's also an i16, not a u16. Once the high bit is set, the number actually becomes negative.

[clairechingching]

this is a good find! would a warning be helpful? since LLVM generates code, i don't want to stop our assembler from generating code

[alnoki]

As stupid as it this, this actually matches the behavior of LLVM. It's also an i16, not a u16. Once the high bit is set, the number actually becomes negative.

@deanmlittle thanks for the correction on the offset type. I got u16 from the SBPF ISA portion about Rust equivalents:

The following Rust equivalents assume that:
- `src` and `dst` registers are `u64`
- `imm` is `u32`
- `off` is `u16`

but after your comment took a closer look and found the i16 definition at ebpf::Insn::off. Accordingly I edited the description since the problematic behavior is now even more likely to happen, and submitted anza-xyz/sbpf#110 to fix the SBPF ISA

this is a good find! would a warning be helpful? since LLVM generates code, i don't want to stop our assembler from generating code

@clairechingching I understand the motivation behind maintaining feature parity with established tooling, although in this case I'd say that LLVM is itself implementing a massive footgun that should be fixed. I'd suggest:

1. For sbpf
   1. By default, panic on out-of-bounds offsets
   2. Provide an --allow-truncating-offsets flag to suppress the panic and allow silent truncation, with a warning
2. Expand your LLVM contribution base by upstreaming the same behavior to save many more people many more headaches

Your thoughts?

[clairechingching]

i don't disagree what you said, and i'll definitely look more into this (and thanks for submitting a PR to fix Anza's doc!). BUT it's unlikely upstream would accept the change. Erroring out something that's used to work might cause massive failure (even a new warning could trip CI/CD pipelines)

i think we can definitely do better by providing a warning in our toolchain : )

[alnoki]

i don't disagree what you said, and i'll definitely look more into this (and thanks for submitting a PR to fix Anza's doc!). BUT it's unlikely upstream would accept the change. Erroring out something that's used to work might cause massive failure (even a new warning could trip CI/CD pipelines)

i think we can definitely do better by providing a warning in our toolchain : )

@clairechingching Unless this defaults to a panic (which is of course my preference), at the very least a warning would of be useful, and ideally some kind of flag like --panic-on-warnings since I suspect there may be more issues like this and I'd rather not have to pass chains of --panic-on-truncation-error, --panic-on-another-potential-issue-that-llvm-does-too ,--panic-on-that-other-thing-that-is-DEFINITELY-broken-but-still-also-in-llvm

Since, in the absence of a linter, the only other option is either requiring some kind of custom CI/CD pipeline that greps the entire file and looks for truncation issues, or a fork of sbpf with some kind of hijacking of the AST