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

RFE: Expose module custom sections #2873

Open
FGasper opened this issue May 3, 2021 · 8 comments
Open

RFE: Expose module custom sections #2873

FGasper opened this issue May 3, 2021 · 8 comments

Comments

@FGasper
Copy link

FGasper commented May 3, 2021

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Module/customSections

^^ I may just be missing it, but I don't see an interface in wasmtime that corresponds to this one. Would it be possible to add this? (And also in the C API?)

Thank you!

@alexcrichton
Copy link
Member

Sorry for the delay in responding here, but thanks for the report!

While wasmtime doesn't currently yet expose an API for this, you can pretty easily build one with the wasmparser crate:

use wasmparser::{Parser, Payload, Result};

fn custom_sections(bytes: &[u8]) -> impl Iterator<Item = Result<(&str, &[u8])>> {
    Parser::new(0).parse_all(bytes).filter_map(|payload| {
        let payload = match payload {
            Ok(s) => s,
            Err(e) => return Some(Err(e)),
        };
        match payload {
            Payload::CustomSection { name, data, .. } => Some(Ok((name, data))),
            _ => None,
        }
    })
}

Would that work for your purposes? Or is there a reason you need an API added to wasmtime itself?

@FGasper
Copy link
Author

FGasper commented May 20, 2021

Is wasmparser available from C? I’m using this from Perl so would need something I can call from C.

Thank you!

FYI, there’s also discussion of adding such an interface to the standard C API:
WebAssembly/wasm-c-api#168 (comment)

@alexcrichton
Copy link
Member

There is not currently a C API for wasmparser, so if you don't want to write Rust code then this will need to wait until there's a C API binding for this in Wasmtime's C API.

@ajihyf
Copy link

ajihyf commented Nov 11, 2022

Sorry for the delay in responding here, but thanks for the report!

While wasmtime doesn't currently yet expose an API for this, you can pretty easily build one with the wasmparser crate:

use wasmparser::{Parser, Payload, Result};

fn custom_sections(bytes: &[u8]) -> impl Iterator<Item = Result<(&str, &[u8])>> {
    Parser::new(0).parse_all(bytes).filter_map(|payload| {
        let payload = match payload {
            Ok(s) => s,
            Err(e) => return Some(Err(e)),
        };
        match payload {
            Payload::CustomSection { name, data, .. } => Some(Ok((name, data))),
            _ => None,
        }
    })
}

Would that work for your purposes? Or is there a reason you need an API added to wasmtime itself?

Hi, this approach only accepts raw wasm input. Is it possible to get custom sections from a module which may be deserialized from compiled artifact?

@bjorn3
Copy link
Contributor

bjorn3 commented Nov 11, 2022

I don't think we preserve custom sections in precompiled modules.

@ajihyf
Copy link

ajihyf commented Nov 14, 2022

I'm using dynamic linking to run multiple module instances with the same linear memory. The custom section naming "dylink.0" is required to provide proper imports to instantiate the modules. It seems that wasmer supports custom section query API like JavaScript, which works both in raw and compiled modules. Maybe wasmtime should preserve the custom sections, too?

@alexcrichton
Copy link
Member

To confirm, precompiled artifacts don't store custom sections so this API would not be possible. I'd recommend extracting the custom section and saving it adjacent or next to wasmtime's compiled artifact.

@stevefan1999-personal
Copy link

This is needed for Den now. For now I have to mask it with not implemented...pity

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

No branches or pull requests

5 participants