Add wasm_c_api for source debugger

[cimacmillan]

What

Add an API to wasm_c_api.h that will allow starting a source debugger on an IP and port

Why

This is currently implemented in the wasm_export.h API, however we need to instantiate WAMR through the wasm_c_api.h for modules support.

https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/source_debugging.md

[cimacmillan]

I have some time allocated to improving debugging support. I was thinking of picking this up towards the end if I am able.

I've temporarily hacked it by:

• Initialising WAMR through both the wasm_c_api and wasm_export api
• Getting the execution env for the wasm_c_api module inst by re-defining the wasm_instance_t struct locally to get the inst_comm_rt
• Use wasm_runtime_get_exec_env_singleton from the inst_comm_rt

So far it seems to be working but should be patched up as it requires us keeping a local definition of wasm_instance_t & wasm_host_info that need to be kept up to date with WAMR version

[nchamzn]

I think an issue here will be that wasm_c_api is implementing https://github.com/WebAssembly/wasm-c-api which does not have any API for debugger.

[loganek]

Yes, I think we'll either have to propose a new version of the C API that adds support for debugging, or have extra API for WAMR headers. I think updating the C API is something we should bring to WASM debugging subgroup with a proposal, but I don't even know what's the current status and whether they're already discussed the problem. We can sync with them, but in parallel, I think we might consider adding extra API to WAMR to have a way to obtain wasm module instance (IIRC, that's what you need, we don't need the full definition of that structure exposed) when the instance is created using wasm_instance_new*.

[lum1n0us]

Agree. wasm_instance_new_with_args might be a good start point.

[bnason-nf]

I have a similar issue, where I would like to be able to have debugging support (using the wasm_export API) but would also like to be able to get all the imports and exports from a module (using the wasm_c_api). Would it be possible to support more wasm_c_api features in wasm_export until extensions like debug support are in the official C API?

[lum1n0us]

Would it be possible to support more wasm_c_api features in wasm_export until extensions like debug support are in the official C API?

@bnason-nf 👋 Would you mind giving a specific list about APIs are required?

[bnason-nf]

Hi @lum1n0us, thanks for the quick response. I don't have a complete list since I just ran into this, but here is the initial list:

wasm_module_imports()
wasm_importtype_module()
wasm_importtype_name()
wasm_importtype_type()
wasm_externtype_kind()
wasm_importtype_is_linked()
wasm_importtype_vec_delete()
wasm_module_exports()
wasm_exporttype_name()
wasm_exporttype_type()
wasm_exporttype_vec_delete()

[bnason-nf]

My goal is just to get the arrays of imports and exports, so it could be completely different APIs in wasm_export of course.

[lum1n0us]

I guess we can make it happen. Just my curious, why don't use wasm_c_api.h directly?

[bnason-nf]

If wasm_c_api provided all of the functionality that wasm_export did, I could use it. The main example of that is the one from the original issue here, debugging. It seems in general neither of these APIs is a superset of the other, each API offers something that the other does not.

[bnason-nf]

Hi @lum1n0us,

Would it be better if I opened a new issue to track this? Also, would it be helpful if I put together a PR?

Thanks, Benbuck

[lum1n0us]

Yes and Yes. And I am sure we can start some discussion based on a ongoing PR.