[dartaotruntime] Support ELF linking or appending snapshot as ELF data section

[ntkme]

When executing a self-contained executable (dartaotruntime + aot-snapshot), the way we get snapshot is first File::ReadLinkInto("/proc/self/exe", ...), and then attempt to read snapshot from the file path as following:

sdk/runtime/bin/main.cc

Lines 1190 to 1191 in 8e7b111

	if (Platform::ResolveExecutablePathInto(executable_path, kPathBufSize) > 0) {
	app_snapshot = Snapshot::TryReadAppendedAppSnapshotElf(executable_path);

sdk/runtime/bin/platform_linux.cc

Lines 157 to 163 in 24683da

	const char* Platform::ResolveExecutablePath() {
	return File::ReadLink("/proc/self/exe");
	}
	intptr_t Platform::ResolveExecutablePathInto(char* result, size_t result_size) {
	return File::ReadLinkInto("/proc/self/exe", result, result_size);
	}

However, /proc/self/exe is not a reliable way to get the path to current executable. It can be broken in a few ways, but in particular when the executable is explicitly launched via ld-linux. Here is a demonstration:

$ /usr/bin/readlink -f /proc/self/exe
/usr/bin/readlink
$ /lib64/ld-linux-x86-64.so.2 /usr/bin/readlink -f /proc/self/exe
/usr/lib/x86_64-linux-gnu/ld-2.31.so

The behavior of dartaotruntime is affected by this, that when launching via ld-linux, the call to Snapshot::TryReadAppendedAppSnapshotElf(executable_path) will effectively read ld-linux and not be able to correct locate the embedded aot-snapshot inside the elf binary, for which it will simply behave as running a normal dart vm instead of running the aot snapshot.

This is the root cause of: sass/dart-sass-embedded#78, please see discussion on user impact there. Interestingly, it seems on certain linux distribution or with certain config, this issue is present even if the user is directly launching the executable without explicitly invoking ld-linux from command line. In such case, it is a bigger issue as all self-contained executables are broken on such platform.

[mraleph]

@ntkme Do you actually have a reproduction for the issue outside of loading through runtime linker directly? Because if that's the only case when it breaks - I would be tempted to mark this low priority. The real fix here is to start doing real linking and stop doing concatenation of files, which we have been using as a stop gap solution.

[ntkme]

Personally I don’t have a way to reproduce it other than invoking through the linker, but it did happen for one user when invoking directly: sass/dart-sass-embedded#78 (comment)

Unfortunately, that user stopped replying the thread so that we don’t know much about the environment and configuration where it happened.

[ntkme]

Another way to break this is use patchelf to modify the interpreter, which is common for NixOS users. Technically it is a different issue but closely related. As patchelf don’t understand the magic offset, once the binary is patch the offset would be wrong: sass-contrib/sass-embedded-host-ruby#91 (comment)

[mraleph]

Yeah, the issue with patchelf has the same underlying reason - doing real linking (or at the very least real ELF sections editing) is the answer.

[NANASHI0X74]

I tried to package a dart executable for nixos and apparently I've run into this exact issue.

[NANASHI0X74]

@mraleph you said that the concatenating of aot snapshots was a stopgap solution, but are there any plans or ongoing efforts to do the real linking as you suggested? 😄

[mraleph]

No ongoing effort at the moment, sorry. If you want to distribute AOT compiled Dart code to the OS where our current approach breaks then your next best option currently is to distribute AOT snapshot and AOT runtime as separate binaries and have a shell script which wraps these two things together.