Ability to redirect file IO to jvm level file handling

[mikehearn]

GNU Coreutils likes to close stdout/stderr in an atexit handler. This has the annoying side effect that if anything goes wrong during execution, the exception info is not printed to the screen.

There are some hacky ways to fix this, but I suspect the real fix is to install intrinsics that redirect libc file IO to Java's own file IO APIs. That way, we can swap stderr/stdout for separate streams before executing a C program and it can't tamper with the Java programs streams. Also it'd let you map views of Java NIO FS providers into the C/C++ programs view, e.g. to read data in JAR files.

[pekd]

There is no problem with closing stdout/stderr. You can do the same with Java, with exactly the same effect:

public class CloseStderr {
	public static void main(String[] args) throws Exception {
		System.err.close();
		// nothing is printed to stderr:
		throw new Exception();
	}
}

The file descriptors stdin/stdout/stderr are standardized, and the JVM uses exactly the same file descriptors as you use in your C/bitcode programs. You cannot "redirect" the native file descriptors in to "Java's own file IO APIs", because the JVM already uses the same file descriptors. Also keep in mind that it is possible to transfer file descriptors to arbitrary processes using UNIX domain sockets.

Accessing Java's NIO FS providers should be possible (in the future?) by using the language interop feature.

[mikehearn]

I understand why it happens. And perhaps this is a quirk only coreutils has, in which case it doesn't matter much.

But Sulong effectively virtualises the execution of the program. That means it actually can redirect the file descriptors behind the scenes (e.g. dup and relabel them) if it chooses to, along with many other things.

Allowing a custom library to override/overlay libc and then using truffle interop would be a good way to do FS redirection indeed.