diff --git a/DEBUGGING.md b/DEBUGGING.md
index b6844866824..42e560e31ed 100644
--- a/DEBUGGING.md
+++ b/DEBUGGING.md
@@ -18,7 +18,9 @@ perform the following operations:
To produce binaries with the Kotlin/Native compiler it's sufficient to use the ``-g`` option on the command line.
_Example:_
-```
+
+
+```bash
0:b-debugger-fixes:minamoto@unit-703(0)# cat - > hello.kt
fun main(args: Array) {
println("Hello world")
@@ -52,57 +54,106 @@ Process 28473 stopped
(lldb)
```
+
+
### Breakpoints
Modern debuggers provide several ways to set a breakpoint, see below for a tool-by-tool breakdown:
#### lldb
- by name
-````
+
+
+
+```bash
(lldb) b -n kfun:main(kotlin.Array)
Breakpoint 4: where = terminator.kexe`kfun:main(kotlin.Array) + 4 at hello.kt:2, address = 0x00000001000012e4
-````
+```
+
+
+
_``-n`` is optional, this flag is applied by default_
- by location (filename, line number)
-````
+
+
+
+```bash
(lldb) b -f hello.kt -l 1
Breakpoint 1: where = terminator.kexe`kfun:main(kotlin.Array) + 4 at hello.kt:2, address = 0x00000001000012e4
-````
+```
+
+
+
- by address
-````
+
+
+
+```bash
(lldb) b -a 0x00000001000012e4
Breakpoint 2: address = 0x00000001000012e4
-````
+```
+
+
+
- by regex, you might find it useful for debugging generated artifacts, like lambda etc. (where used ``#`` symbol in name).
-````
+
+
+
+```bash
3: regex = 'main\(', locations = 1
3.1: where = terminator.kexe`kfun:main(kotlin.Array) + 4 at hello.kt:2, address = terminator.kexe[0x00000001000012e4], unresolved, hit count = 0
-````
+```
+
+
+
#### gdb
- by regex
-````
+
+
+
+```bash
(gdb) rbreak main(
Breakpoint 1 at 0x1000109b4
struct ktype:kotlin.Unit &kfun:main(kotlin.Array);
-````
+```
+
+
+
- by name __unusable__, because ``:`` is a separator for the breakpoint by location
-``
+
+
+```bash
(gdb) b kfun:main(kotlin.Array)
No source file named kfun.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (kfun:main(kotlin.Array)) pending
-``
+```
+
+
+
- by location
-````
- (gdb) b hello.kt:1
- Breakpoint 2 at 0x100001704: file /Users/minamoto/ws/.git-trees/hello.kt, line 1.
-````
+
+
+
+```bash
+(gdb) b hello.kt:1
+Breakpoint 2 at 0x100001704: file /Users/minamoto/ws/.git-trees/hello.kt, line 1.
+```
+
+
+
- by address
-````
+
+
+
+```bash
(gdb) b *0x100001704
Note: breakpoint 2 also set at pc 0x100001704.
Breakpoint 3 at 0x100001704: file /Users/minamoto/ws/.git-trees/hello.kt, line 2.
-````
+```
+
+
+
### Stepping
Stepping functions works mostly the same way as for C/C++ programs
@@ -113,7 +164,9 @@ Variable inspections for var variables works out of the box for primitive types.
For non-primitive types there are custom pretty printers for lldb in
`konan_lldb.py`:
-```
+
+
+```bash
λ cat main.kt | nl
1 fun main(args: Array) {
2 var x = 1
@@ -156,11 +209,16 @@ Process 4985 launched: './program.kexe' (x86_64)
(lldb)
```
+
+
+
Getting representation of the object variable (var) could also be done using the
built-in runtime function `Konan_DebugPrint` (this approach also works for gdb,
using a module of command syntax):
-````
+
+
+```bash
0:b-debugger-fixes:minamoto@unit-703(0)# cat ../debugger-plugin/1.kt | nl -p
1 fun foo(a:String, b:Int) = a + b
2 fun one() = 1
@@ -196,7 +254,10 @@ Process 80496 launched: './program.kexe' (x86_64)
(lldb) expression -- Konan_DebugPrint(a_variable)
(a_variable) one is 1(KInt) $0 = 0
(lldb)
-````
+
+```
+
+
### Known issues