Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions crates/polkavm-common/src/program.rs
Original file line number Diff line number Diff line change
Expand Up @@ -5230,6 +5230,10 @@ impl ProgramBlob {

/// Parses the given bytes into a program blob.
pub fn parse(bytes: ArcBytes) -> Result<Self, ProgramParseError> {
let blob_length = Self::blob_length(&bytes).ok_or(ProgramParseError(ProgramParseErrorKind::Other(
"blob does not contain the blob length",
)))?;
let bytes = bytes.subslice(0..blob_length as usize);
Comment on lines +5233 to +5236
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

In general I meant doing this outside of PolkaVM code in downstream code; that's why I said to make subslice public, so that you don't need any special support for it here. :P

The .polkavm blob is essentially supposed to be self-contained; if you want to append/prepend data to it then you're welcome to do so, but I don't want to be responsible for handling that data. I'm probably going to e.g. also supply official APIs to write .polkavm blobs in the future (including an API to loselessly convert back and forth), and I just don't want to deal with all of the miscellaneous variations of adding extra metadata that explicitly avoids the intended way of adding such metadata (as a dedicated section inside the file), especially since I have no way of knowing how to handle such grafted metadata correctly.

And the proliferation of different PVM "blob" formats is not a theoretical issue, we already have these different formats:

  • Vanilla .polkavm blob as my tooling builds it
  • JAM service blob (metadata header + minimal PVM header + PVM code sections)
  • CoreVM service blob (metadata header same as JAM service blob + full .polkavm blob)
  • The contracts blob (full .polkavm blob + appended data)

The .polkavm blob was explicitly designed to be extensible so that this isn't necessary! But instead everyone just invents their own flavor, so I'm drawing a line in the sand - I can provide APIs to make the grafting of extra metadata possible, but I don't want to have to deal with it in my core crates.

Copy link
Copy Markdown
Member Author

@xermicus xermicus Jan 13, 2026

Choose a reason for hiding this comment

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

I see the point but ignoring extra data wouldn't be part of the format? How I see it, the only thing it does is making the parser a bit more resilient. It also avoids us to maintain a custom version of polkatool.

Isn't it more like an ELF file with trailing data can still be parsed by readelf and objdump and you can still execute it fine?

let parts = ProgramParts::from_bytes(bytes)?;
Self::from_parts(parts)
}
Expand Down
2 changes: 1 addition & 1 deletion crates/polkavm-common/src/utils.rs
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ impl ArcBytes {
}
}

pub(crate) fn subslice(&self, subrange: Range<usize>) -> Self {
pub fn subslice(&self, subrange: Range<usize>) -> Self {
if subrange.start == subrange.end {
return Self::empty();
}
Expand Down