Indirect Calling of Nested Functions on GCC Without Executable Stack(uecker.codeberg.page) |
Indirect Calling of Nested Functions on GCC Without Executable Stack(uecker.codeberg.page) |
It seems silly to expose a tiny helper to the entire compilation unit when it is only meant to be used inside one function…
Because GCC's nested functions are closures - they can access local variables within the function.
I realized that, instead of a configuration file, I could configure the executable instead! So, any changes in configuration meant the editor would patch its own exe file!
This marvelous technique came to an end when attempts to stop malware got folded into the operating system.
The overhead of cache flushing means some old school techniques are no longer viable, like modifying a constant in the next instruction. However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines. I had a case where I had RGB masks like R=0x00ff0000 etc (loaded at startup once) and wanted to convert 0x00rrggbb to match the mask (so no-op in the common case but not always) which could have involved setting the shift amounts in a series of shift instructions.
The Linux kernel uses self-modification to change branches depending on whether certain features are on. For example when a user-mode process starts tracing a certain function, it adds code to the beginning of that function to trace the call, otherwise it pads that space with a no-op. JIT compilers also make good use of knowing whether a class has any subclasses, which is statically unknowable in Java but dynamically knowable.
I'm still working my way through it so it's possible that I've misunderstood this section, though, and one question I haven't answered is how they get around the typical restriction on w+x pages.
[0] Particularly this one https://www.airs.com/blog/archives/41
There is also JIT (like in regexp engines), but it's different story.
> Only a limited number of indirect targets that cross a 64MB aligned boundary relative to the branch address can be tracked in the indirect target predictor. Software should limit the number of indirect branch targets that cross such a boundary.
And one way doing this is to replace the indirect branch with a direct branch, which supports a 32-bit signed displacement.
That trampoline needs to live somewhere. Since the function is inherently noncallable after the stack returns, and C programmers hate it when their compiler sneaks in extra malloc calls under the hood, the compiler decides to stick the trampoline on the stack instead of heap-allocating it.
But now the stack needs to be executable.
I remember once learning of a runtime environment that would inline class functions. For example they wrote an OS, and if you had an object of a SATA hard drive class, it would copy the function code and inline the drive ID. I don't remember how well it worked for them.
A related idea is the "tracing JIT". You know how you expect a JIT to translate one function at a time? A tracing JIT doesn't - it follows the program logic wherever it goes, through whatever control flow, and compiles all of it until it decides to stop. The most well known implementation is probably LuaJIT.
For example, I have a program that opens Adobe Acrobat Reader as an out-of-process COM server, but tends to leave phantom Acrobat processes hanging around after it quits. To fix this, I wrap CreateProcess in a function that adds any Acrobat processes created to a job object[2] set up to make Windows automatically kill them when the application closes.
[1] https://github.com/microsoft/detours
[2] https://learn.microsoft.com/en-us/windows/win32/procthread/j...
- Static calls: like a call to a global function pointer, except instead of loading a function pointer and doing an indirect call, the code is patched to do a direct call to the destination
- Static keys: like an if statement testing a global boolean, except instead of loading a boolean and doing a conditional branch, the code is patched to do either an unconditional branch or a nop
- Runtime constants: like a load of a global variable, except instead of loading, the value is patched directly into the code
- Alternatives: selects one of multiple possible instruction sequences depending on (usually) whether the CPU supports specific instructions
It's really fascinating to see the kind of fun efficient stuff you can do when you have that level of low-level control. Not just code patching but things like RCU as well.
> However it is still interesting to write machine code snippets once and execute them many times, like the nested function trampolines.
I slightly disagree on this though. In my experience writing code with Clang blocks (which don't use trampolines), they're often useful for code organization even if the callback will only be called once. Therefore, even ignoring security issues, I think GCC choosing a design that required cache flushing was a mistake - certainly in retrospect (as cache flushing has become more expensive over the years), but perhaps even at the time. I did some research, and trampolines were introduced in GCC 2.0, which already included mprotect calls and/or cache flushes on some of the architectures it supported, such as MIPS. However, this was a relatively new development, and on most of the supported architectures it didn't do either of those things. But on MIPS it would do an mprotect every single time a trampoline was created, which can't have been fast.
BTW you can do all of this cool stuff in user mode on Linux too (but not on OpenBSD) - you just have to opt in to executable stack and/or writable .text. I could have written the dynamic shift instruction generator I mentioned, but I didn't want to spend the effort, but I imagined having a language with actual support for something like that (like static keys for variables).
Your program is either front-end stalled by uop count or instruction cache latency, or back-end bound by memory bandwidth or ALU throughput or a serial dependency chain. It doesn't matter which is the bottleneck for this case, because inlining constants improves most of the above!
When the back end is the bottleneck, the front end stalls and vice versa, though I'm not sure how all processors report it.
D has the notion of a "delegate", which is a (function pointer) and (context pointer) pair. This is incredibly useful, because delegates can:
1. call nested functions that need a pointer to the stack frame of the nestee function
2. call member functions that need `this` pointer
3. call lambdas
4. call COM member functions
The neato thing about this is the ABI for delegates is all the same, so a function that gets a delegate parameter will work with any of 1..4. It's one of the most used features of D.
This was true for the original TeX78 written in Sail, as well as the ultimate TeX82 written in Knuth's WEB macro language on top of Pascal (that nowadays typically gets transpiled to C). Other programs did similar stuff; the feature was in the OS way before TeX started.
(Gory detail: Actually, TeX went a little further, to free up all possible address space for the final executable: The version that could initialize various hash tables and hyphenation trie tables could dump (nee serialize) a binary file of the resulting data structures; then a slimmed-down version that didn't have that code would read the binary info back in to recreate the initial data structure state, and that's what you'd SAVE the production executable from.)
For the unix-y versions of TeX, there was effort made to mimic this sort of thing in user-land with "undump", but admirable as it was, it was a hack, I'm told. These days, everything is so fast, it's not clear that this feature would be worth it anyway.
Source: me; I was there.
The program loader is not magic - it just reads a list of things to mmap and then mmaps them. If you write a thing that writes a list of what's mmapped and call it the unloader... fine?
Lisp Machines though.. updating the operating system was by loading bunch of compiled files that replaced currently loaded functions in memory.
Then again, Lisp Machines where very proud of self modification — the CADR had a fun feature where it could modify the next instruction depending on things…
How the world has changed.
The description is a bit confusing because it can both dump only the warmed up interpreter image or the whole process, I think.
"With the program undump, you can use `core' to reconstitute a preloaded executable, which does not need to read a `.fmt' file to get started. Although preloaded executables save startup time, they have a big disadvantage: neither the disk space to store them nor their code segments (at runtime) can be shared. Therefore, if both tex and latex are running, twice as much memory will be consumed, to the general detriment of performance."
https://mirror.gutenberg-asso.fr/tex.loria.fr/texlive-htmldo...
Not exactly the entire process image, no, but essentially all of its data in a single chunk. It’s a peculiar Pascal program because it bypasses basically all of Pascal’s typing, records, etc., and instead builds its own from a set of (WEB) macros on top of a giant untyped array. Quoth Knuth in TeX: The Program §115:
> The dynamic storage requirements of TeX are handled by providing a large array mem in which consecutive blocks of words are used as nodes by the TeX routines. Pointer variables are indices into this array [...].
There are a few more areas designated for specific purposes, but at the end of the day (§1302) it works out about the way you’d expect:
procedure store_fmt_file;
[...] begin ⟨ If dumping is not allowed, abort 1304 ⟩
⟨ Create the format ident, open the format file, and inform the user that dumping has begun 1328 ⟩;
⟨ Dump constants for consistency check 1307 ⟩;
⟨ Dump the string pool 1309 ⟩;
⟨ Dump the dynamic memory 1311 ⟩;
⟨ Dump the table of equivalents 1313 ⟩;
⟨ Dump the font information 1320 ⟩;
⟨ Dump the hyphenation tables 1324 ⟩;
⟨ Dump a couple more things and the closing check word 1326 ⟩;
⟨ Close the format file 1329 ⟩;
end;They just chucked the old system for a portable version of it, but until this last release, they still had to option of doing it the old school way.
Choosing between ADM-3A or ANSI terminals by running "WINSTALL" would rewrite the main Wordstart executable WS.COM appropriately for example.
But because ISA was mentioned, x86 does indeed even have native support for this: https://devblogs.microsoft.com/oldnewthing/20231211-00/?p=10... These instructions are not too useful though and I do not think anybody uses them.
Supporting closures, more or less, requires design decisions that are equivalent to choosing a specific layout for objects in an object-oriented language. C, as it is, makes none of these assumptions and you can translate a lot of different language ABIs into some C code (that may be clumsy). Keeping the abstraction that function pointers = pointers to entry points for functions, well, that’s frustrating for C programmers writing C programs, but extremely useful for interoperability.
> we simply need a code pointer and static chain pair
The code pointer and chain pair needs an object layout. You would have to pick a specific layout, and it would not be compatible with other languages that have a different layout.
Right now I can do this:
struct a {
void (*fun)(void *ctx);
int data1;
int data2;
};
struct b {
void (*fun)(void *ctx);
void *ctx;
};
struct a *aptr;
a->fun(aptr);
struct b *bptr;
b->fun(bptr->ctx);
If you add closures to C you are making compatibility worse, not better.
Adding such a type as a vocabulary type would fix all this. You can argue that we fix an object layout for a pointer pair, but this seems an acceptable trade-off to me. This seems far from your previous claim that this "requires design decisions that are equivalent to choosing a specific layout for objects in an object-oriented language." Note also that such a type can always adapt to different calling conventions of other languages by using the address of a static thunk as code pointer so it is very generic.