Svyatoslav Scherbina
4774912fdc
Currently, when generating a TypeInfo with a vtable attached, the K/N compiler generates two globals to the resulting LLVM module: - "ktypeglobal:$fqName#internal" -- an internal global of the aggregate type (TypeInfo+vtable) - "kclass:$fqName" -- an internal or hidden alias pointing to the TypeInfo part of that global The reason for emitting two globals is to have everything strict-typed, since other LLVM modules might import the kclass as a TypeInfo. Importing an aggregate TypeInfo+vtable global as a TypeInfo global works too, of course. It is just a little bit less clean. The new Xcode 15 linker now emits symbols for the ktypeglobal to the symbol table, including an STSYM. This happens for classes compiled to cache, when the kclass is hidden, not internal. The problem is: for some reason, such an STSYM for "ktypeglobal:kotlin.String#internal" makes lldb find a wrong address (0xffffffffffffffff) for "kclass:kotlin.String", despite those being two different symbol names. This seems to be related to them having the same address though. The K/N lldb script, konan_lldb.py, uses "kclass:kotlin.String" to determine if an object is a string, in order to display it properly. Therefore, using the new Xcode 15 linker when compiling with caches makes the debugger unable to display string variables properly. As a side effect, this also breaks displaying array-typed variables (because the script first checks if an object is a string). This commit fixes this by removing ktypeglobals completely, making the compiler emit only a kclass as an aggregate global directly. Now, there are other ways to fix the problem. For example, making the ktypeglobal private instead of internal, or making konan_lldb.py use a runtime function instead of querying "kclass:kotlin.String" directly. But it seems that LLVM aliases are not common on darwin platforms. For example, Clang doesn't support `__attribute__((alias(...)))` on these platforms. So it is safer to just stop using aliases here. ^KT-61417
Kotlin/Native
Kotlin/Native is an LLVM backend for the Kotlin compiler, runtime implementation, and native code generation facility using the LLVM toolchain.
Kotlin/Native is primarily designed to allow compilation for platforms where virtual machines are not desirable or possible (such as iOS or embedded targets), or where a developer is willing to produce a reasonably-sized self-contained program without the need to ship an additional execution runtime.
Using published Kotlin/Native versions
The most complete experience with Kotlin/Native can be achieved by using Gradle, IntelliJ IDEA or Android Studio with KMM plugin if you target iOS.
If you are interested in using Kotlin/Native for iOS, then Kotlin Multiplatform Mobile portal might be useful for you.
Command line compiler is also available.
More information can be found in the overviews of Kotlin/Native and Kotlin Multiplatform.
On macOS Kotlin/Native requires Xcode 12.5 or newer.
Contributing
You can contribute to Kotlin/Native in many ways. See the relevant page on the website.
See also the general contribution guidelines for this repository.
Building from source
Prerequisites:
- configure Kotlin build as specified in main readme
- at the root directory of the repository,
create
local.propertiesfile withkotlin.native.enabled=trueline - macOS: Xcode 14.0 or newer
-
on
MacOS aarch64, CInterop functionality is available only using aarch64 JDK builds, e.g. Eclipse Temurin 17.0.5 or Azul Zulu JDK8Note: using
JDK x86_64onMacOS aarch64will causejava.lang.UnsatisfiedLinkErrorforlibclang.dylib
-
- Linux: glibc 2.23 or newer
- Windows:
- Microsoft C++ build tools for Visual Studio 2019 14.29 or newer
- Windows SDK 10.0.18362.0 or newer
The commands below should be run from either repository root or this (kotlin-native/) directory.
For the latter, :kotlin-native: task name prefix can be omitted.
To compile the basic compiler distribution from sources, run following command:
./gradlew :kotlin-native:dist
It will build compiler and stdlib for host target, without platform libraries.
To get platform libraries, add distPlatformLibs task, e.g.
./gradlew :kotlin-native:dist :kotlin-native:distPlatformLibs
To run the full build:
./gradlew :kotlin-native:bundle
This will produce compiler and libraries for all supported targets. The full build can take about an hour on a Macbook Pro.
After any of the commands above, ./dist will contain Kotlin/Native distribution.
You can use it like a distribution of
command-line compiler.
Or configure Gradle to use it -- just add the following line to
gradle.properties in your Gradle project:
kotlin.native.home=/path/to/kotlin/kotlin-native/dist
To compile your programs with command-line compiler, use:
./dist/bin/kotlinc-native hello.kt -o hello
For an optimized compilation, use -opt:
./dist/bin/kotlinc-native hello.kt -o hello -opt
Interoperability
To import a C or Objective-C library, use ./dist/bin/cinterop tool.
See the documentation for more details.
Note: on MacOS aarch64, JDK aarch64 is required
Running tests
For tests, use ./gradlew :native:native.tests:codegenBoxTest and ./gradlew :kotlin-native:backend.native:tests:run.
Note: on MacOS aarch64, for target-specific tests, JDK aarch64 is required
For more details see Testing.
More tips and tricks
More tips and tricks that might be useful when developing or debugging Kotlin/Native can be found in HACKING.md