Skip to content

Use [u8] instead of [u16] to not rely on alignment #736

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

Merged
merged 7 commits into from
Feb 14, 2025

Conversation

zhouwfang
Copy link
Contributor

#46

@zhouwfang zhouwfang requested a review from ia0 as a code owner February 10, 2025 23:38
Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

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

Thanks! We shouldn't need to use bytemuck anymore and can write our own parse_u16 and parse_u32 functions (probably with toctou).

branch_table_view: Default::default(),
})
}

pub fn metadata(&self, func_idx: usize) -> Metadata<'m> {
Metadata(
&self.metadata[self.indices[func_idx] as usize .. self.indices[func_idx + 1] as usize],
&self.metadata
[self.indices[func_idx * 2] as usize .. self.indices[(func_idx + 1) * 2] as usize],
Copy link
Member

Choose a reason for hiding this comment

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

This is wrong, we need to read 2 bytes. We could use a parse_u16(offset: usize) -> u16 helper which simply does u16::from_le_bytes(self.binary[offset..][..2].try_into().unwrap()) or something like that.

Also, we probably shouldn't panic if the side table is corrupted during verification. If some functions are used both in Check and Use mode, then we need to make them generic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems this function is only used in next_branch_table() for the Verify mode. Do you mean we should return Result<Metadata<'m>, Error> instead?

Copy link
Member

Choose a reason for hiding this comment

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

It's because Module::side_table is currently wrong. It will be the SideTableView eventually, and then it will use this function to access the parser range and branch table.

Yes, I mean we should return MResult<Metadata<'m>, M>. And Module::new_unchecked() should do the initial parsing. This could be done in another PR though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you basically mean prepare() should return SideTableView?

Copy link
Member

Choose a reason for hiding this comment

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

No, prepare() is not concerned. It's only Module::new_unchecked(). More generally, it's only relevant for parsing (views) and not formatting (prepare()).

Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

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

Thanks! It's getting closer.

@zhouwfang zhouwfang requested a review from ia0 February 14, 2025 03:14
Copy link
Member

@ia0 ia0 left a comment

Choose a reason for hiding this comment

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

Thanks!

Ok(SideTableView {
func_idx: 0,
indices: parse_side_table_field(parser)?,
metadata: parse_side_table_field(parser)?,
indices: &binary[2 .. indices_end],
Copy link
Member

Choose a reason for hiding this comment

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

The TODO below also applies to this function. In particular, we should use .get(2 .. indices_end) to return an error instead of panicking.

@@ -65,15 +59,23 @@ impl<'m> Metadata<'m> {
}

pub fn branch_table(&self) -> &[BranchTableEntry] {
bytemuck::cast_slice(&self.0[5 ..])
let entry_size = size_of::<BranchTableEntry>();
assert_eq!(
Copy link
Member

Choose a reason for hiding this comment

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

Same here, we probably want to use MResult.

@ia0 ia0 merged commit b254c7e into google:dev/fast-interp Feb 14, 2025
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants