On the question of debugging, dependencies, etc (a...

# kotlin-native

[kpgalligan]

On the question of debugging, dependencies, etc (a thread -->)

[kpgalligan]

I’ve been working on the lldb formatting scripts to enable a better GUI debugging experience (for Xcode but also hopefully AppCode and whatever else uses lldb: https://github.com/JetBrains/kotlin-native/pull/2972).

[kpgalligan]

I don’t know the internals of lldb and how llvm ties source and binary, but I’ve been able to infer a few things.

[kpgalligan]

When compiling local, setting breakpoints to those local files works fine. This does not work with dependencies, however. The local path to dependency source, and the path “compiled” with the klib differ

[kpgalligan]

For dependencies I’ve published personally, from this machine, I can add those source paths to Xcode and debug, and looking at the binaries, it does appear that those absolute paths are included in builds (but this is where my understanding gets shaky).

[kpgalligan]

Is there some thought to (optionally) including source in klibs, and while compiling having some way of tying the binary output and lldb breakpoint capability to that local klib source? Say exploding them in the build directory somewhere? Doing a deep dive on how the compiler outputs debug info is on the todo list, but that seems like a fairly steep learning curve, so thought I’d just open up this discussion now as I have no idea when I’ll get around to that.

[olonho]

makes perfect sense, @Vasily Levchenko may help with understanding of details. Generally, absolute paths are stored in output format called DWARF (and klib too), so they have to be fixed if come from another machine.

[Vasily Levchenko]

Hello, Kevin, we’re investigation options we have here. at the moment you can manually download sources and configure debugger to use them https://lldb.llvm.org/use/map.html

[kpgalligan]

Thanks for the info. Will think about this a bit. I had a gradle plugin set up to download source jars and explode them in the build dir. It would be possible to map lldb, but obviously it’s a case by case mapping because the libraries are likely built on different machines. Alternatively, it might be possible in the near term to repackage the klib (presumably program.kt.bc) with local paths, but this isn’t really a huge priority. Just something that would be useful down the road.