Custom Sections API

[syrusakbary]

A user of Wasmer has just requested usage of the custom section API via our C bindings.

Wasmer is basing their new API based on Wasm-C-API, but it doesn't have an API yet for accessing data in custom sections. So it would be great to add one!
What you think the ideal API for accessing custom sections via Wasm-C-API would be? Do you think that's something the project would benefit from? (if so, we will be super happy to open a PR/proposal!)

More context: wasmerio/wasmer#2285

[Hywan]

Proposed API:

WASM_API_EXTERN void wasm_module_custom_sections(
    const wasm_module_t* module,
    const wasm_name_t* name,
    own wasm_byte_vec_t** out,
);

where:

• module represents the module potentially containing the custom sections,
• name represents the desired custom section's name,
• out represents an array of wasm_byte_vec_t, containing the custom sections whom name is matching name (since more than one custom sections can have the same name, we must return an array).

The ownership of name doesn't need to transfered to wasm_module_custom_sections in this case I think. The user might want to re-use the name several times after the function execution (in a hashmap for example, stuff like that).

If name has no match in the custom section list, out will be an empty array.

To make things simpler, we could create a new type: wasm_custom_section_t (as an alias to wasm_byte_vec_t) and wasm_custom_section_vec_t; thus the proposed API will become:

typedef wasm_byte_vec_t wasm_custom_section_t;
WASM_DECLARE_VEC(custom_section, )

WASM_API_EXTERN void wasm_module_custom_sections(
    const wasm_module_t* module,
    const wasm_name_t* name,
    own wasm_custom_section_vec_t* out,
);

Thoughts?

[rossberg]

Ah, note that a wasm_module_t represents an already decoded module, which isn't necessarily expected to keep a reference to the binary it originated from. So the API will need to extract custom sections from binaries, not module objects.

[FGasper]

Additional note: @Hywan’s proposal seems to encompass only a lookup; it would seem more ideal if the API were a lister/iterator pattern?

e.g.:

typedef struct {
    wasm_name_t* name;
    wasm_byte_vec_t* data;
} wasm_custom_section_t;

wasm_new_custom_sections( wasm_byte_vec_t wasm_bytes, wasm_custom_section_t** sections )

(Please forgive the inexactitude of the above … I’m still rather new to WASM.)

[syrusakbary]

Ah, note that a wasm_module_t represents an already decoded module, which isn't necessarily expected to keep a reference to the binary it originated from. So the API will need to extract custom sections from binaries, not module objects.

On the JS API, the object taken for customSections is a Module Object (instead than a vec of bytes):
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Module/customSections

At Wasmer we also store those custom section bytes in the compiled Artifact of the module. I guess it's likely that if V8 adds some caching to Wasm Compiled objects (if doesn't have it yet), a similar approach will be taken? (since it saves more space only storing the custom sections along the compiled artifact than saving the whole Wasm file with the compiled artifact).

Do you think is worth to mimic the JS API behavior in C? (taking a object module instead of a vec of wasm bytes).