[clang] [clang][WebAssembly] Handle casted function pointers with different number of arguments (PR #153168)

[Derek Schuff via cfe-commits]

dschuff wrote:

> The cost is unavoidable if the developer wants the webassembly ABI to work like other ABIs, where you simply pass fewer arguments than the ones expected, and don't change their own code. The proposed approach mimics such behavior; indeed, some collateral potential problems might occur, but that's the purpose of having an optional flag and knowing the implications.

This is part of what I'm trying to understand about the use case. Namely, exactly who has to know the implications? (equivalently, who would need to enable this flag)? is it just the GLib core developers? Or is it everyone who wants to link against GLib?

> The signals are not the problem; is the whole GOBject inheritance model that is based on this ABI assumption. It is difficult for me to find a middle ground here ...

This phrasing suggests that everyone who wants to use GLib has calls in their code (or at least their object files) that need to use mismatched signatures. The fact that IIUC you were able to make things work with hacks that were localized to GLib means that your changes just leaked into public headers?
 

> Nevertheless, there is a misunderstanding in the documentation about the EMULATE_FUNCTION_POINTER_CASTS as it has nothing to do with the number of arguments, only with the type of arguments.

EMULATE_FUNCTION_POINTER_CASTS (implemented by Binaryen's [fpcast-emu](https://github.com/WebAssembly/binaryen/blob/main/src/passes/FuncCastEmulation.cpp) transformation pass) makes all indirect calls use the same number of arguments, and creates thunks that pass those calls through with the right number of arguments. So it should fix both the number and type of arguments.

That was actually one question I had for you about the patch you wrote here vs EMULATE_FUNCTION_POINTER_CASTS, namely whether EMULATE_FUNCTION_POINTER_CASTS actually worked and was sufficient for GLib (it was unclear from the discussion; also a side question was if so, how bad was the performance effect?). It should work for both number and type of arguments, but it only works for indirect calls.


https://github.com/llvm/llvm-project/pull/153168