| commit | 6ef57b86c1ba78d291726b273e345a2df33f16b6 | [log] [tgz] |
|---|---|---|
| author | Daco Harkes <dacoharkes@google.com> | Fri Jan 20 10:30:41 2023 |
| committer | Daco Harkes <dacoharkes@google.com> | Fri Jan 20 10:30:41 2023 |
| tree | 9ca567541c377f3b435c500e3faba5e641b18ff6 | |
| parent | 7e60e54575461cc5b9074e7e1bccacea7f6faacf [diff] |
[vm/ffi] Support varargs This CL introduces `VarArgs` to `NativeFunction` signatures. The `VarArgs` type takes a single type argument. This type argument is a subtype of `NativeType` if there is a single variadic argument, and a record with native types if there are multiple variadic arguments. For example: `NativeFunction<Void Function(Pointer<Char>, VarArgs<(Int32,Int32)>)>` for calling refering to a `printf` binding with two `int32_t` arguments passed as variadic arguments. The logic of the native calling conventions are detailed in https://dart-review.googlesource.com/c/sdk/+/278342. Here we explain how this influences the FFI pipeline. First, now that `VarArgs` is part of signatures, we have to unwrap that when with the C types in the CFE transform and checking (analyzer is in a separate CL), and also in the marshaller when looking up the C type of arguments. Second, we have to deal with `BothNativeLocations`. On windows x64, floating point arguments must be passed both in FPU _and_ CPU registers. For FFI calls, we solve this in the argument moves by just copying to both locations. For FFI callbacks, we just take the FPU register location (which avoids an extra bitcast). Third, on System-V, we have to pass an upper bound of the number of XMM registers used in AL. This means we instead RAX, we use R13 for the target address. For variadic calls, we always pass 8 in AL as the valid upper bound. We could consider passing the actual number of XMM registers used. We keep using RAX as default register for the function address on non- variadic calls, because changing to R13 (the first free) register creates more spilling in leaf calls. R13 is callee-saved while RAX is not, so using R13 instead of RAX causes us to have to spill the value from RAX on leaf calls. Fourth, on both x64 and RISC-V, we pass floats in integer locations. `EmitNativeMove` has been modified to deal with this, so that we do not have to insert more `BitCastInstr`s. The tests are generated by a test generator: `tests/ffi/generator/`. The formatter doesn't support records yet, so the tests are not properly formatted. Bug: https://github.com/dart-lang/sdk/issues/50798 TEST=tests/ffi/*_varargs_* Closes: https://github.com/dart-lang/sdk/issues/38578 Closes: https://github.com/dart-lang/sdk/issues/49460 Closes: https://github.com/dart-lang/sdk/issues/50858 Change-Id: I6a6296fe972527f8a54ac75a630131769e3cc540 Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-win-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-nnbd-win-release-ia32-try,vm-kernel-nnbd-win-debug-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-kernel-precomp-android-release-arm64c-try,vm-kernel-precomp-android-release-arm_x64-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-precomp-ffi-qemu-linux-release-riscv64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,app-kernel-linux-debug-x64-try,vm-kernel-mac-release-arm64-try,vm-kernel-nnbd-mac-debug-arm64-try,vm-kernel-nnbd-mac-debug-x64-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/276921 Reviewed-by: Devon Carew <devoncarew@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.