HomePhabricator

[ORC] Add a runAsMain utility function to ExecutionUtils.

Authored by lhames on Dec 2 2019, 1:45 AM.

Description

[ORC] Add a runAsMain utility function to ExecutionUtils.

The runAsMain function takes a pointer to a function with a standard C main
signature, int(*)(int, char*[]), and invokes it using the given arguments and
program name. The arguments are copied into writable temporary storage as
required by the C and C++ specifications, so runAsMain safe to use when calling
main functions that modify their arguments in-place.

This patch also uses the new runAsMain function to replace hand-rolled versions
in lli, llvm-jitlink, and the SpeculativeJIT example.

Details

Committed
lhamesDec 2 2019, 1:52 AM
Parents
rG0e7ecc651a47: [ExecutionEngine] Add a jitTargetAddressToFunction utility function.
Branches
Unknown
Tags
Unknown

Event Timeline

Looks like this broke argument handling in orc-lazy mode for lli.
Given a bitcode version of a main2.c like this:

#include <stdio.h>
int main(int argc, char *argv[]) {
  for (int i = 0; i < argc; i++)
    printf("%d: %s\n", argv[i]);
  return 0;
}

I'd expect this output:

> lli -jit-kind=orc-lazy main2.ll -o output input
0: main2.ll
1: -o
2: output
3: input

However, with this patch applied I am now getting:

lli -jit-kind=orc-lazy main2.ll -o output input
0: lli
1: main2.ll
2: -o
3: output

I will look into it.

Hi Stefan,

Thanks again for spotting this. I’ve fixed it and added a test case in 2cdb18afda8.

— Lang.

I was about to say enjoy your time off and have a look here on Monday: D72563 I guess we don't need it anymore :)
Is there a particular reason to pass lli as the program name instead of the main source file? Not saying that this made a lot of sense in the first place, just wondering.

I was about to say enjoy your time off and have a look here on Monday: D72563 I guess we don't need it anymore :)

Sorry — I had a spare moment on the train home and couldn’t resist fixing this up.

Is there a particular reason to pass lli as the program name instead of the main source file? Not saying that this made a lot of sense in the first place, just wondering.

Not really. The change I introduced was unthinking (I had just been mechanically updating JIT’d main calls) so I thought I would switch it back to the previous behavior with this fix. In general if clients want to JIT programs that are usually compiled AOT then there is one argument for using the path to lli: Programs that inspect their first argument and expect to find an executable at that path will break if we use the bitcode path/name. As far as I know LLI never provided any guarantees of fidelity with the standard execution environment though, so I don’t think it’s a big problem if we break this.