Add WasmFileKeyGenerator for split Wasm symbol files

[paolosevMSFT]

Adds support for indexing WebAssembly modules on symbol servers by introducing a WasmFileKeyGenerator that parses Wasm binaries and extracts the build_id custom section.

This enables uploading and retrieving both halves of split-debug Wasm files. (It follows the same convention as ELF (elf-buildid vs elf-buildid-sym):

• Stripped Wasm modules => indexed with wasm-buildid prefix
• Symbol files (containing DWARF .debug_* sections) => indexed with wasm-buildid-sym prefix

Changes:

• New: WasmFileKeyGenerator class that validates the Wasm header, scans custom sections for build_id, and detects symbol files via .debug_* sections
• Modified: FileKeyGenerator to include WasmFileKeyGenerator in the auto-detection chain
• Tests: Added unit tests with synthetic Wasm binaries covering plain modules, symbol files, and files without build IDs

[Copilot]

Pull request overview

Adds WebAssembly module support to Microsoft.SymbolStore key generation by introducing a WasmFileKeyGenerator that extracts a build_id custom section and distinguishes stripped vs split-debug Wasm files via .debug_* custom sections, enabling symbol-server indexing using wasm-buildid and wasm-buildid-sym prefixes.

Changes:

• Added WasmFileKeyGenerator to parse Wasm headers/sections, extract build_id, and detect DWARF debug sections.
• Updated FileKeyGenerator auto-detection chain to include Wasm support.
• Added unit tests covering Wasm modules, symbol files, and missing build IDs.

Reviewed changes

Copilot reviewed 3 out of 6 changed files in this pull request and generated 3 comments.

File	Description
src/tests/Microsoft.SymbolStore.UnitTests/KeyGeneratorTests.cs	Adds unit tests for Wasm key generation (module vs symbol file vs missing build_id).
src/Microsoft.SymbolStore/KeyGenerators/WasmFileKeyGenerator.cs	Introduces the Wasm key generator and parsing logic for build_id and .debug_* sections.
src/Microsoft.SymbolStore/KeyGenerators/FileKeyGenerator.cs	Adds Wasm detection to the generic file key generator chain.

Comments suppressed due to low confidence (1)

src/Microsoft.SymbolStore/KeyGenerators/WasmFileKeyGenerator.cs:184

• nameStart is assigned but never used here as well; with TreatWarningsAsErrors enabled this breaks the build. Remove the unused local variable.

                    if (sectionId == CustomSectionId)
                    {
                        long nameStart = stream.Position;
                        string name = ReadWasmString(stream);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[paolosevMSFT]

@dotnet-policy-service agree company="Microsoft"

[paolosevMSFT]

Could someone review this? Who are the right reviewers?
(I don't see any UI to assign a reviewer to this PR...)
Thanks!

[leculver]

This read could read past secondEnd, along with my comment below on clamping the number of bytes ReadWasmString reads, maybe we should pass sectionEnd to ReadWasmString and also ensure we don't read past the end of the section?

[leculver]

This should probably go at the end of the try block in case we hit an exception.

[noahfalk]

@thaystg - could you take a look at this?

@paolosevMSFT - is there any existing standard you aware of around this? So far the only convention we have documented is for unsplit wasm files. If we are creating new conventions I think the place we should start is updating the spec and get some understanding of what tools/scenarios we expect will initially consume this.

[paolosevMSFT]

@noahfalk

The primary scenario is serving split Wasm DWARF symbols from Microsoft symbol servers for Chromium DevTools, via the DWARF-C/C++ DevTools Extension.

The build_id custom section is already produced by the emscripten toolchain (-gseparate-dwarf -Wl,--build-id) and reported via CDP's Debugger.scriptParsed (https://chromedevtools.github.io/devtools-protocol/1-3/Debugger/) event. However, there's currently no symbol server support for indexing split Wasm symbols by build ID, which is exactly what this PR enables.

This is the server-side piece needed to close the loop: toolchain produces build_id => symbol server indexes by build_id => debugger fetches symbols using build_id.

I'm happy to update SSQP_Key_Conventions.md to document this. Would you prefer that as a prerequisite or in parallel?