Skip to content

Binary Reading: Don't pick internal names for things that overlap with the name section #7700

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kripken
Copy link
Member

@kripken kripken commented Jul 7, 2025

This can only really happen in the fuzzer, but it is annoying there:
we can have fimport$17 in the names section, and before this
fix, we could pick that as the implicit name for something without
a name section entry. The fix is just to note names from the
names section in the list of used names.

@kripken kripken requested a review from tlively July 7, 2025 20:54
Comment on lines +2521 to +2522
// We found a name in the names section. Use it, and also note it as used
// so we don't generate such a name below, later.
Copy link
Member

Choose a reason for hiding this comment

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

Is there anything stopping us from generating a name below and later running into it in the names section?

Copy link
Member Author

Choose a reason for hiding this comment

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

I believe this code aims to avoid that, be pre-populating the names:

void WasmBinaryReader::readFunctionSignatures() {
size_t num = getU32LEB();
auto numImports = wasm.functions.size();
std::unordered_set<Name> usedNames;
for (auto& [index, name] : functionNames) {
if (index >= num + numImports) {
std::cerr << "warning: function index out of bounds in name section: "
<< name << " at index " << index << '\n';
}
usedNames.insert(name);
}

But that raises the question of why that didn't fix this issue. Unfortunately, I can only reproduce this with an experimental pass not yet in a PR, so I don't have a good testcase. Anyhow, let's hold off on this until that PR is ready.

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