Conversation
Replying to
Check out this insanity: github.com/mozilla/gecko-. The normal choices are a library being extracted to the file system or having it mapped directly from the apk by having it uncompressed. Instead, Firefox uses lazy loading by intercepting segfaults when libraries are used.
2
1
2
Replying to
The latter kinda makes sense because the particular OS is so broken (vendor libs that call signal) but yes it's stupid that they're doing it to begin with.
1
Replying to
The library they're talking about is a cross-platform GPU driver, and GPU drivers are in general full of insane code. They like setting up all kinds of trampolines and alternate stack shenanigans so they are full of hard-wired hacks just like Firefox, which often conflict.
2
1
Something else that comes to mind is libffi. It implements FFI via a JIT compiler generating trampolines, and they have hard-wired support for SELinux execmem where they work around support for dynamic code generating being disallowed in-memory by doing it via /tmp. Yet...
1
... a proper policy will disallow doing it via the filesystem in any way too. Only something like a package manager generally actually needs to expose the attack surface of being able to create files which could be executed. They could definitely handle normal cases without JIT.
1
cgit.freedesktop.org/mesa/mesa/tree is not as bad since it just disables an optimization, which if I recall correctly is totally unnecessary. A lot of GPU drivers have a JIT simply as a way of removing one layer of function calls. It becomes more and more normal for everything to have a JIT.
1
Replying to
Here's the libffi one which I absolutely despise since it's very widespread:
github.com/libffi/libffi/
The library exists to provide dynamic FFI instead of needing wrapper libraries, which I've come to regard as a bad idea beyond the JIT compiler. People get the signatures wrong.
1
2
It means people are hard-wiring the signatures of C functions in other languages, often in a much less portable way. For example, by using `int` for a type that is only `int` on some platforms. There's no type checking, just the dynamically generated trampolines at runtime.
1
1
You can see how crazy it is from this little tutorial:
pgi-jcns.fz-juelich.de/portal/pages/u
It's hard-wired in Python so whatever complexity exists in the C headers for portability across platforms is easily missed. You get memory corruption at runtime from a mistake, with no sanity checks.
Replying to
Are you familiar with my claim that the only FFI into C, ever, should be via an embedded virtual machine for a simple ISA and an isolated ecosystem of C binaries built for this ISA that can be shipped as target-independent assets?
1
Replying to
Languages with ahead-of-time compilation can incorporate libclang into their toolchain to implement native calls into C with proper static checking and without boilerplate. A dynamic language could essentially do the same thing by requiring compilation to make use of C FFI.
2
Show replies