turran wrote: Hello @dschuff, thanks for getting back to this issue
> I can see that trying to fix up callsites in Binaryen transparently is > probably infeasble, although I still have basically the same objections the > proposed approach that were expressed by @efriedma-quic and myself above. > > I'm doing some prototyping experiments with different approaches, and the way > I'm validating them is to try locally modifying glib to support Emscripten > and get the tests to pass (at least, the ones that don't depend on > unsupported posix features). I hope to have more to say different approaches > shortly. But the first thing I tried was to apply this patch to clang, and > then try to see whether it is sufficient to make glib work. The first > approach was to turn a coding agent loose and let it try to make the tests > pass. This doesn't result in upstreamable changes, but it does identify > places in the code that must be modified. > As I mentioned before, keep in mind that the GLib maintainers have a strict stance on the potential changes to address this situation. Check https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/toolchain-requirements.md?ref_type=heads#function-pointer-conversions. They state that the toolchain must handle function pointer mismatch; any other attempt will be discarded, as it already happens to us in a MR we opened. > And it appears that this patch is not sufficient to make glib transparently > work. Mostly because there are plenty of casts in glib that are actually > runtime casts and not compile-time casts. For example in > [gslist.c](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-48030e2aa9b604d2a85bf174ef9ea31ef32d5341128d6317544d88a2551f82bbL1032-R1039) > the list iteration functions are calling callbacks that are either > 2-argument `GCompareFunc` or 3-argument `GCompareDataFunc`, but it can't tell > statically which one it is; the cast is a runtime cast. LIkewise > [g_queue_foreach](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-3196da21408e1f1c02f7923adfdd6680077d395feeeceff925665e711f4c7cb9L84-L87) > does runtime casts on callbacks of type `GFunc` (2 arguments), but can't > tell statically when it gets a function that only takes one argument (like > `free_func` in the example). > > It doesn't seem like a flag that has these drawbacks and only implements part > of a solution is worth it. Correct. The current approach only handles static, compile-time casts, not runtime casts. The same as the former WebAssemblyFixFunctionBitcasts. Even if only static handling is done, it fixes the main problem with GType inheritance, enabling a fully functional GStreamer port to WebAssembly (gst.wasm). If this has a go, the runtime check implementation is also doable. Do you want me to include that as part of this PR? https://github.com/llvm/llvm-project/pull/153168 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
