Add platform-specific entrypoint codegen

[brson]

rbpf-tests contains this comment

 match result {
        Ok(0) => {}
        Ok(_) => {
            // fixme rbpf expects a function that returns a status code, but we
            // currently emit a main function that returns void, so this value
            // is seemingly whatever happens to be in the return register.
        }

Main functions in move (scripts) have no return value, but rbpf expects a status code return value. At the moment we emit the Move main function as the entrypoint, with no wrapper. We need to instead emit some platform-specific entry-point glue to encapsulate the Move main function.

Here's a possible way to do it in the short-term:

• if the module is a script, before translating functions, call a method to emit a platform-specific entrypoint function with a known platform-specific symbol name (I think that name is currently "main")
• that calls the "real" main function with a known name like "__move_main".
• always return 0 (errors in move scripts manifest as abort syscalls).
• when translating functions, when we see the Move main function, give it the name "__move_main". the move model gives this function a placeholder name like "<SCRIPT>", and today we rename it "main"; instead rename it "__move_main".
• change rbpf-tests to treat a return value of Ok(x) if x > 0 as an unexpected failure.

[nvjle]

Additionally, the Move language allows an entry modifier on module functions. This permits those functions to be invoked in the same way as scripts-- as a "main" function where Move programs start executing.

module 0x100::m {
    public entry fun foo() { ... }
}

Thus each of these entry functions will similarly need a platform-specific entry-point glue/wrapper as will be done for the script main entry point .

[nvjle]

PR #251 implements this for Move entry points.

[ksolana]

Is https://github.com/solana-labs/move/issues/182 a duplicate of this ticket?

[nvjle]

Is #182 a duplicate of this ticket?

182 deals with Move "entry" functions, while the original theme of this issue refers to the script main function.

As an aside: Both 180 and 182 are redundant as they merely restate what is already in 161.

[ksolana]

ah, maybe we can close the rest then?

[nvjle]

ah, maybe we can close the rest then?

Yes.

[ksolana]

Does https://github.com/solana-labs/move/pull/319 fix this issue?

[dmakarov]

I think it does, although I didn't make changes rbpf-tests that would use the code returned by entrypoint. Incidentally, I'm inclined to move away from rbpf-tests towards more testing in usual Move unit test style using move-cli, similar to stdlib tests, and decommissioning move-mv-llvm-compiler completely. It's never going to be used by the end users.

[nvjle]

I think it does, although I didn't make changes rbpf-tests that would use the code returned by entrypoint. Incidentally, I'm inclined to move away from rbpf-tests towards more testing in usual Move unit test style using move-cli, similar to stdlib tests, and decommissioning move-mv-llvm-compiler completely. It's never going to be used by the end users.

My 2 cents: I also tend to agree that it makes sense to migrate to the standard Move unit-test framework instead of rbpf-tests. Having a bespoke framework probably made sense early in the project, but maybe not so much today. Likewise, migrating to the usual move-cli for compilation also seems to make sense at this stage of the project. No need to continue to duplicate work or reinvent the wheel-- especially now that some of us are (or will be) juggling Move, runtime, and LLVM work essentially simultaneously.