Skip to content
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

[API Proposal]: Get wasm custom sections inside assembly #112649

Open
fsmoke opened this issue Feb 18, 2025 · 7 comments
Open

[API Proposal]: Get wasm custom sections inside assembly #112649

fsmoke opened this issue Feb 18, 2025 · 7 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript needs-author-action An issue or pull request that requires more info or actions from the author. no-recent-activity
Milestone

Comments

@fsmoke
Copy link

fsmoke commented Feb 18, 2025

Background and motivation

WASM binary format allow to add custom sections for any additional information, for example we use it for storing some meta information of our product. but Our investigation did not find out how to read these information direct from within the executing assembly(on browser client).

My suggesstion to add ability of reading custom WASM sections at runtime

API Proposal

namespace System.Reflection;

public class Wasm
{
    public static WasmModule GetExecutingModule();
    ...
}

public class WasmModule 
{
    public virtual IEnumerable<WasmSection> CustomSections  => GetCustomSections();
    public WasmSection[] GetCustomSections() { code here };
    ...
}

public class WasmSection
{
    public string Name; 
    public WasmSectionTypesEnum Type;
    public byte[] Data => GetData();
    public byte[] GetData() { code here };
    ...
}

API Usage

var wmodule = Wasm.GetExecutingModule();
var zero_sect = wmodule.GetCustomSections()[0];
var name = zero_sect.Name;
var data = zero_sect.Data;

Alternative Designs

No response

Risks

No response

@fsmoke fsmoke added the api-suggestion Early API idea and discussion, it is NOT ready for implementation label Feb 18, 2025
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Feb 18, 2025
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Feb 18, 2025
@vcsjones vcsjones added arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Feb 18, 2025
Copy link
Contributor

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

@teo-tsirpanis
Copy link
Contributor

Can you encode these metadata as assembly attributes? Accessing them will become much easier this way.

@fsmoke
Copy link
Author

fsmoke commented Feb 19, 2025

Can you encode these metadata as assembly attributes?

No, this metadata writed after build, because some .NET components of our system used in several independant projects

For example our build steps

Building Common Components Step
Building Component 1
Building Component 2

Building Project 1 Step
Use Component 1
Deploy(copy) Component 1 to Bin directory of Project 1
Write metadata of project in all binaries (native dlls, native so(if linux), managed dlls, wasm files and etc) inside Bin directory of Project 1
Sign all binaries inside Bin directory of Project 1

Building Project 2 Step
Use Component 1
Use Component 2
Deploy(copy) Component 1 to Bin directory of Project 2
Deploy(copy) Component 2 to Bin directory of Project 2
Write metadata of project in all binaries (native dlls, native so(if linux), managed dlls, wasm files and etc) inside Bin directory of Project 2
Sign all binaries inside Bin directory of Project 2

Component 1 and Component 2 are common assemblies - and build server compile these assemblies only once

@pavelsavara
Copy link
Member

pavelsavara commented Feb 27, 2025

Let's figure out how to actually read the information at runtime.

AFAIK, the browser API doesn't offer this introspection.
So the solution would be to get the wasm bytes (from browser cache by fetch) and parse it yourself.

2 years ago I did parser in TS as an experiment, it's not that bad.

@radekdoulik has managed parser, maybe that's better suited for the task.

Overall I think it's not necessary for runtime to implement this.
It could and should be 3rd party community component.

@fsmoke could you please share more about your use-case ?

@radekdoulik
Copy link
Member

If you know the section name, which seems to be your case, you can use the https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/Module/customSections_static method to retrieve the custom section data on the JS side.

Image

@pavelsavara pavelsavara added the needs-author-action An issue or pull request that requires more info or actions from the author. label Feb 27, 2025
Copy link
Contributor

This issue has been marked needs-author-action and may be missing some important information.

@pavelsavara pavelsavara added this to the Future milestone Feb 27, 2025
@pavelsavara pavelsavara removed the untriaged New issue has not been triaged by the area owner label Feb 27, 2025
Copy link
Contributor

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation arch-wasm WebAssembly architecture area-System.Runtime.InteropServices.JavaScript needs-author-action An issue or pull request that requires more info or actions from the author. no-recent-activity
Projects
None yet
Development

No branches or pull requests

5 participants