Introduction

The Kotlin debugger uses inline marker variables ($i$f$..., $i$a$...) that are produced by the Kotlin compiler to handle stepping into/over/out of inline functions and lambdas and also to build inline stack traces. This scheme does not work for dex code, where the same variable may be duplicated in different registers and where basic blocks can be reordered. This leads to many debugging issues on Android from inconsistent locals in the variables view to bad stepping in inline functions.

New format description

The new format affects 3 types of variables:

1. Inline function marker variables $i$f$name\[scope number]\[call site line number]
2. Inline lambda marker variables $i$a$name\[scope number]\[call site line number]\[surrounding scope number]
3. Local variables from inline functions or lambdas name\[scope number]

Let’s break it down on the following example:

fun main() {
  val inMain = 0
  g(0) {
    val inLambdaG1 = 1 // breakpoint 1
    h()
    g(4) {
      val inLambdaG2 = 2 // breakpoint 2
    }
  }
}

inline fun g(gParam: Int, block: () -> Unit) {
  block()
}

inline fun h() {
  val inH = 3
  i()
}

inline fun i() {
  val inI = 4
}

How LVT used to look:

LocalVariableTable:
Start  Length  Slot  Name   Signature
    20      4     7  $i$f$i   I
    23      1     8  inI$iv$iv   I
    14     11     5  $i$f$h   I
    17      8     6  inH$iv   I
    34      4     7  $i$a$-g-SandboxKt$main$1$1   I
    37      1     8  inLambdaG2   I
    31      9     6  $i$f$g   I
    28     12     5  gParam$iv   I
     8     33     3  $i$a$-g-SandboxKt$main$1   I
    11     30     4  inLambdaG1   I
     6     37     2  $i$f$g   I
     4     39     1  gParam$iv   I
     2     42     0  inMain   I

How LVT looks with the new format:

LocalVariableTable:
Start  Length  Slot  Name   Signature
   20       4     7  $i$f$i\4\30   I
   23       1     8  inI\4   I
   14      11     5  $i$f$h\3\7   I
   17       8     6  inH\3   I
   34       4     7  $i$a$-g-SandboxKt$main$1$1\6\36\2   I
   37       1     8  inLambdaG2\6   I
   31       9     6  $i$f$g\5\8   I
   28      12     5  gParam\5   I
    8      33     3  $i$a$-g-SandboxKt$main$1\2\28\0   I
   11      30     4  inLambdaG1\2   I
    6      37     2  $i$f$g\1\5   I
    4      39     1  gParam\1   I
    2      42     0  inMain   I

Previously the compiler added the $iv suffixes to distinguish locals that belong to different inline functions. Now we assign scope numbers to marker and local variables. Locals with a scope number belong to the function which is represented by a marker variable with the same scope number.

Let’s see how it works in our example:

• $i$f$g\1\5 has scope number 1, as well as gParam\1.
• $i$a$-g-SandboxKt$main$1\2\28\0 has scope number 2, as well as inLambdaG1\2. It also has a surrounding scope number equal to 0. The scope number 0 belongs to the top frame, and basically means that the inMain variable should be included in the variables view when we stop at breakpoint 1.
• $i$f$h\3\7 has scope number 3, as well as inH\3.
• $i$f$i\4\30 has scope number 4, as well as inI\4.
• $i$f$g\5\8 has scope number 5, as well as gParam\5.
• $i$a$-g-SandboxKt$main$1$1\6\36\2 has scope number 6, as well as inLambdaG2\6, and surrounding scope number 2, which means that we should include variables that are visible in scope 2 when we stop at breakpoint 2. In our example these variables are inMain and inLambdaG1\2.