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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to