WIP: Embed APE loader inside APE

[lemaitre]

This is an implementation of the loader proposal from #263.

The idea is to embed inside the APE a tiny ELF that loads the APE in memory, and jump into it to start it. The loader is copied into TMP folder and started from here. The loader is from Justine's example: 969174e.

Before considering merging, I would like some feedbacks, especially about how to organize the new code, and where to put it.
Also, I won't be able to create a MacOs loader, so I might need some help here.

[jart]

Welcome as a new contributor. We need to go through one quick hurdle before we can proceed. Could you please email Justine Tunney [email protected] and say that you intend to assign her the copyright
to the changes you contribute to Cosmopolitan? See CONTRIBUTING.md for further details. We make the ask because it helps us ship the tiniest most legally permissive prim and proper binaries.
You also only need to do it one time, so any future changes you send us can be quickly merged.

[jart]

Nice

[jart]

1. I would recommend having this only happen for the ape-no-modify-self.o build.
2. You might want to check $(uname -s) = Linux

[lemaitre]

I was in the impression that, if a system-wide ape-loader exist, it is always the right thing to do.
The copy of the embedded loader is done only if APE_LOADER is defined, which, I expect, happens only for ape-no-modify-self.o.

I need a separate macro, as APE_LOADER gives the path of the loader ELF.

I just copied the test for Linux/MacOS which was already here. The check for the existence of a directory is faster than calling uname in a subshell.

[lemaitre]

Could you please email Justine Tunney [email protected] and say that you intend to assign her the copyright
to the changes you contribute to Cosmopolitan?

I've just sent it to you from my personal email.

[lemaitre]

I've ran some benchmarks about how fast the loader is:

native	direct loader	shell loader	shell loader + copy
1.52 ms	1.57 ms	8.07 ms	15.7 ms

The binary tested is hello.com (with stdout redirected to /dev/null).
So the loader by itself is really fast and have a negligible impact.
However, the shell trick alone accounts for about 5-6 ms, and the copy of the loader takes another 7 ms.

All in all, I think it's reasonable, especially because this overhead does not increase with the size of the APE.

[jart]

LGTM Thank You!

especially because this overhead does not increase with the size of the APE.

That's definitely the best part!

The 5ms constant factor can be using something like binfmt_misc or, more ideally, getting ape support merged into kernels.

[lemaitre]

@jart I know you were eager to merge this, but I think it was not ready yet (hence the "WIP" prefix in the name).
To me there were a few questions that needed answers:

• Should we have a test for a system-wide ape-loader before trying anything else?
• When copying the loader in the temp folder, should we randomize the destination a bit?
• Should we keep the old code for copying the whole APE (in case the loader is not embedded)?

Maybe I could just create an issue to discuss this, and the another MR when we have answers.