The new latest version (commit 806789e4d454b, 307 bytes) should also work. It no longer sets p_memsz to something unreasonably large, which was most likely the issue with the 301-byte and 298-byte versions from a few days ago.
Looks like I may have stretched what values are acceptable for p_filesz/p_memsz too far. What's your kernel version? (I tested it on 6.8.0 and 4.4.0.) Perhaps the 316-byte version at commit 451827cfd5399074 (before that particular hack was introduced) would work.
GP is likely referring to how fields in the ELF and program header are abused for instructions and data in a way that happens to not break things on Linux.
If the savings are about `mov $1, %edi` and `mov $10, %ecx`, those 32-bit immediate values line up with the higher bytes of p_filesz and p_memsz in the program header, which have to be zero [1]. If not, what are the savings? :)
The person is also quite good at specifically putting their words online in a way that others can benefit from them. (Enough so that it’s a bit of a running joke[1] when he quits his job and has time to write some more words.) That skill is generally difficult to transmit, so if they’re saying something in that direction it could be worth listening.
