How to traverse the module tree?

[t4lz]

If I want to write a wasm to wasm tool using Binaryen, that adds some logic into a wasm module, how do I traverse and modify the module's tree?
Do I have to write a pass, or is there a way to do that using the outward facing C(++)-API of Binaryen?
One could start by iterating up to BinaryenGetNumFunctions(...), getting each Function with BinaryenGetFunctionByIndex(...), and BinaryenFunctionGetBody(...), but is the function body always a block, even if the original function code only contains one instruction? And say I know it's a block, and I take BinaryenBlockGetChildAt(...), How do I know what kind of expression that is (Loop? If? etc.)?
If the right thing to do is to write a pass here, are there any resources available about how to write a Binaryen pass? Can I do it from an external project that just links to the Binaryen c library, or do I have to add my new pass inside the Binaryen codebase?

[kripken]

The C API by itself doesn't have enough, I think.

Using C++, you'd write a module traversal (see wasm-traversal.h, but it is usually easier to read example code in the various passes, I'd say).

You can write that C++ in a new pass inside binaryen, or you can write a new program that uses libbinaryen and the C++ API, externally to binaryen.

(I don't think we have a way to write an external pass atm: binaryen won't scan for passes in a dynamic way, the list is hardcoded. But external code can do pretty much anything else using the C++ API.)

[tlively]

(I don't think we have a way to write an external pass atm: binaryen won't scan for passes in a dynamic way, the list is hardcoded. But external code can do pretty much anything else using the C++ API.)

FWIW, you can use void PassRunner::add(std::unique_ptr<Pass> pass) to run arbitrary passes that are not in the hardcoded list as well.

[t4lz]

Thank you both very much! This is very helpful :)
So since the C++ API makes it possible to write a pass (inherit from WalkerPass) and add it to the PassRunner, I will write my code as a pass. I find it quite cool that binaryen is extensible that way. Instead of just writing my library as a wasm2wasm tool, I will also expose the binaryen pass, so that user code can integrate it in binaryen usage if that code uses binaryen itself anyway for example.
Thanks for explaining the situation and pointing to all the important places.