So, debugging. What are people doing to debug nati...
# kotlin-native
k
So, debugging. What are people doing to debug native code? Specifically I have either command line tests running on a mac or a framework running inside an ios app. My "debugging" is currently log statements. That round trip is pretty terrible. Something better? lldb or similar?
👍 1
p
Print statements are about as good as it gets right now. I first make sure all the tests pass (and get 100% code coverage) on the JVM. Then my native code models the JVM code so that I feel pretty decent about the code coverage but I’ve yet to find an answer to how one truly gets code coverage on native code. I did see a thread recently where CLion was touted as having a decent debugger for native code but I’ve not yet grokked how to set it up and use it. Then there’s GDB which I’ve not used in ~30 years but at least that’s a case of jumping on the that rusty old bicycle.
t
When the K/N plugin was first released for AppCode, I was actually able to single step through the Kotlin code in an iOS project. It was on the slow side, but usable. Hopefully before too long they will update the Kotlin plugin with mpp support and return this debug-ability.
👍 1
l
As I tried, you can set a break point in lldb (XCode) and inspect memory/register status around. Even thought that is not convenient, but definitely doable.
d
Hi @kpgalligan. You can use LLDB to debug Kotlin/Native apps. - First compile your app with debug symbols included. This could be done by adding
-g
command line argument to Kotlin/Native compiler (
konanc
or
kotlinc-native
command). - Then run the app in LLDB console. Something like this:
Copy code
bash-3.2$ lldb myapp.kexe 
(lldb) target create "myapp.kexe"
Current executable set to 'myapp.kexe' (x86_64).
(lldb) breakpoint set -l 24
Breakpoint 1: where = myapp.kexe`kfun:main(kotlin.Array<kotlin.String>) + 14 at Sample.kt:24, address = 0x000000010000894e
(lldb) run 123 hello world
Process 34209 launched: '/Users/dmitriy.dolovov/temp/myapp.kexe' (x86_64)
Process 34209 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000010000894e myapp.kexe`kfun:main(kotlin.Array<kotlin.String>) at Sample.kt:24
   21  	    }
   22  	}
   23  	
-> 24  	fun main(args: Array<String>) {
   25  	    MyApplication().runMe()
   26  	}
Target 0: (myapp.kexe) stopped.
(lldb) s
Process 34209 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step in
    frame #0: 0x0000000100008978 myapp.kexe`kfun:main(kotlin.Array<kotlin.String>) at Sample.kt:25
   22  	}
   23  	
   24  	fun main(args: Array<String>) {
-> 25  	    MyApplication().runMe()
   26  	}
Target 0: (myapp.kexe) stopped.
(lldb) frame var
(ObjHeader *) args = 0x0000000100506df8
- In order to inspect non-primitive values on the frame you will need to apply LLDB formatters for Kotlin/Native:
Copy code
(lldb) command script import ~/.konan/kotlin-native-macos-1.0.2/tools/konan_lldb.py
(lldb) frame var
(ObjHeader *) args = [123', 'hello', 'world']
- And, if you are using the recent version of CLion (2018.3) with up-to-date Kotlin/Native plugin, then debugging is available right in the IDE. Just launch your run configuration in debug mode.
👏 1
k
Interesting, thanks!
s
Also there is a shortcut
konan-lldb
that launches
lldb
and loads
konan_lldb.py
for you.