[dead]
Writing a Self-Mutating x86_64 C Program (2013)
21–30 of 42 posts
Re: Writing a Self-Mutating x86_64 C Program (2013)
#22I often think this could maybe allow fantastic runtime optimisations. I realise this would be hardly debuggable but still..
It sometimes can, but you then have to balance the time spent optimizing against the time spent actually doing whatever you were optimizing.
Also on modern chips you must wait quite a number of cycles before executing modified code or endure a catastrophic performance hit. This is ok for loops and stuff, but makes a lot of the really clever stuff pointless.
The debuggers software breakpoints _are_ self-modifying code :)
Re: Writing a Self-Mutating x86_64 C Program (2013)
#23Earlier quoted context omitted.
It already does, in the form of JIT compilation.
OK but I meant in already native code, like in a C program - no bytecode.
If you are generating or modifying code at runtime then how is that different from bytecode? Standardised bytecodes and JITs are just an organised way of doing the same thing.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#24It's impressive how well laid out the content in this article is. The spacing, tables, and code segments all look pristine to me, which is especially helpful given how dense and technical the content is.
It was designed by Elves on Christmas Island where Dwarves run the servers and Hobbits operate the power plant
Re: Writing a Self-Mutating x86_64 C Program (2013)
#25I often think this could maybe allow fantastic runtime optimisations. I realise this would be hardly debuggable but still..
Linux kernel had the same idea, and now they have "static keys". It's both impressive and terrifying.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#26Fun article, but the resulting code is extremely brittle:
- assumes x86_64
- makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it)
- assumes (as the article acknowledges) that “to determine the length of foo(), we added an empty function, bar(), that immediately follows foo(). By subtracting the address of bar() from foo() we can determine the length in bytes of foo().”. Even simple “all functions align at cache lines” slightly violates that, and I can see a compiler or a linker move the otherwise unused bar away from foo for various reasons.
- makes assumptions about the OS it is running on.
- makes assumptions about the instructions that its source code gets compiled into. For example, in the original example, a sufficiently smart compiler could compile
void foo(void) {
int i=0;
i++;
printf("i: %d\n", i);
}
void foo(void) {
printf("1\n");
}
void foo(void) {
puts("1");
}
Also, why does this example work without flushing the instruction cache after modifying the code?
Re: Writing a Self-Mutating x86_64 C Program (2013)
#27I’ve been thinking a lot about this topic lately, even studying how executables look on arm macOS. My motivation was exploring truly fast incremental compilation for native code.
The only way to do this now on macOS is remapping whole pages as JIT. This makes it quite a challenge but still it might work…
Re: Writing a Self-Mutating x86_64 C Program (2013)
#28Fun article, but the resulting code is extremely brittle: - assumes x86_64 - makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it) - assumes (as the article a…
For the mainstream OSes (Windows, OSX, Linux Android) You don't need to flush the instruction cache on most x86 CPUs after modifying the code segment dynamically, but you do on ARM and MIPS.
This has burned me before while writing a binary packer for Android.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#29It's impressive how well laid out the content in this article is. The spacing, tables, and code segments all look pristine to me, which is especially helpful given how dense and technical the content is.
I have the suspicion that there is a high correlation between how organized the content is, and how organized and clear the mind of the writer is.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#30I guess in OpenBSD because of W ^ X this would not work?
Not as is, but I think OpenBSD permits you to map the same memory twice, once as W and once as X (which would be a reasonable hoop to jump through for JITs etc., except there’s no portable way to do it). ARM64 MacOS doesn’t even permit that, and you need to use OS-specific incantations[1] that essentially prohibit two JITs coexisting in the same process. [1] https://developer.apple.com/documentation/apple-silicon/por…
No, the protection is per-thread. You can run the JITs in different threads