cosmopolitan
cosmopolitan copied to clipboard
When using cosmo_dlopen, functions with a lot of parameters fail
When using functions with more then 4 parameters, the other parameters don't get passed to the function or some odd behavior happens. The fifth parameter doesn't change and the sixth becomes a garbage value.
I initially encountered the issue when trying to use the XCreateImage function from X11.
Here is a repo to repro the issue. I added multiple test cases to validate other potential causes, but only the last test is the offender.
On another note, when we use the malloc from the dll, no system call is outputted when using strace, I have no idea if that is normal behavior. It's probably because we use the --strace from the executable maybe ?
I regret not better documenting this limitation. So here's the reason why that's happening:
https://github.com/jart/cosmopolitan/blob/221a27836b30edfc58663f3196622454c31e8945/libc/dlopen/dlopen.c#L159-L176
Our trampoline needs to be rewritten in assembly code twice, for both x86-64 and aarch64. That way you'll be able to pass large numbers of arguments and floating point parameters safely. It's the kind of thing that's a bit painful to write but can be done. I personally haven't found need of it yet. I intend for this to happen. I will happily merge contributions that make it happen. But I won't volunteer my time to support X11. I'd want to know first, (1) can you work around your issue by passing a struct to a helper function you could write in your own DSO, and (2) anyone else who needs this soon, please chime in and tell us what you're working on!
For now, I can work around this caveat. X11 isn't the end goal, I am actually just trying to get fenster running as a light gui framework.
I can compile fenster as a dll easily. Eventually I want to use something like Kinc or sokol(for 3D) and they will probably need more parameters for some of their functions in their API.
Glad to hear you're not blocked on this one. I'm going to keep this issue open for more feedback, until eventually myself or someone else has time to tackle this.
This issue has been fixed by 0e49bed66.