[swift-dev] JIT-ting Swift

Robert Widmann devteam.codafi at gmail.com
Mon Mar 6 14:37:19 CST 2017


We used to have a callback in the standard library that would set the process arguments, but that approach was fragile and would still have broken here.  Instead, we load the Swift standard library (a step we would have had to do anyway) before entering main and call out to platform-specific functions that grab command line arguments.  Because you’re running on Linux, we’re asking /proc/self/cmdline, but I’m not sure how exactly that interacts with the JIT.  If you’re going to JIT, you should at least follow our lead here by loading the standard library which will in turn load the stubs.  You can override the platform-specific getters by calling out to _swift_stdlib_overrideUnsafeArgvArgc <https://github.com/apple/swift/blob/adc54c8a4d13fbebfeb68244bac401ef2528d6d0/stdlib/public/SwiftShims/RuntimeStubs.h#L40>.

> On Mar 6, 2017, at 3:14 PM, Alex Denisov <1101.debian at gmail.com> wrote:
> 
>> The `main` entry point ought to be a standard C "main" function. The argv argument is an UnsafeMutablePointer<UnsafeMutablePointer<Int8>?>, which ought to be ABI-compatible with a char** in C.
> 
> 
> That was my assumption when I started, thank you for confirmation :)
> 
>> When JIT'ing Swift, the value of argv doesn't matter because we replace the process' arguments dynamically https://github.com/apple/swift/blob/master/lib/Immediate/Immediate.cpp#L318.
> 
> Hm, can you tell a bit more about this? I do not load the runtime, my crash may be caused by something not being initialized.
> Here is my simplified use-case: I compile a swift project with tests into bitcode, then I load the bitcode into memory, and then compile and execute a program using ORC JIT.
> 
>> Do you have a trace for the crash?
> 
> Sure, here it is: https://gist.github.com/AlexDenisov/2a8d9b0d391de73a97bce9e33a650f0f#file-trace-txt-L22-L42
> 
> 
>> On 6 Mar 2017, at 20:14, Robert Widmann <devteam.codafi at gmail.com> wrote:
>> 
>> %Sp is not an argument, it is the space necessary to hold a reference to the CommandLine enumeration's static argv member.  
>> 
>> When JIT'ing Swift, the value of argv doesn't matter because we replace the process' arguments dynamically https://github.com/apple/swift/blob/master/lib/Immediate/Immediate.cpp#L318.  Do you have a trace for the crash?
>> 
>> ~Robert Widmann
>> 
>> 2017/03/06 12:33、Alex Denisov via swift-dev <swift-dev at swift.org> のメッセージ:
>> 
>>> Hi there,
>>> 
>>> I could not find a list for swift-corelibs-xctest so I am posting it here.
>>> 
>>> I am trying to run tests based on XCTest (https://github.com/apple/swift-corelibs-xctest) using LLVM's JIT.
>>> Everything is working good so far. However, I am getting a crash.
>>> Based on a shallow investigation I can see that this is somehow related to the way Swift treats the command line arguments. Or, to be more precise, to the way I pass the arguments to the swift's 'main' function.
>>> 
>>> What I did so far is not different from what I do to run C or C++ using JIT:
>>> 
>>> auto main = ((int (*)(int, const char **))(intptr_t)mainPointer);
>>> const int argc = 1;
>>> const char *argv[] = { "some-name", NULL };
>>> auto result = main(argc, argv);
>>> 
>>> Based on what I see in the IR[1] the 'argv' has type "%Sp = type <{ i8* }>", which seems to be a struct with a pointer to something.
>>> 
>>> So the question is: what is being passed as a second argument to the 'main' function of a swift program?
>>> 
>>> Any other advice on JIT-ting Swift are more than welcome :)
>>> 
>>> [1] https://gist.github.com/AlexDenisov/3c10540b544e82cfb6e58e1452491904
>>> -- 
>>> AlexDenisov
>>> Software Engineer, https://lowlevelbits.org
>>> 
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-dev
> 
> -- 
> AlexDenisov
> Software Engineer, https://lowlevelbits.org
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170306/8a125b17/attachment.html>


More information about the swift-dev mailing list