Updated debugging information

docs/en/en.json

@@ -406,7 +406,11 @@
                     {
                         "path": "/manuals/modules",
                         "name": "Modules"
-                    }
+                    },
+                    {
+                        "path": "/manuals/debugging-game-logic",
+                        "name": "Debugging"
+                    },
                 ]
             },
             {
@@ -458,10 +462,6 @@
                         "path": "/manuals/bob",
                         "name": "Bob the builder"
                     },
-                    {
-                        "path": "/manuals/debugging",
-                        "name": "Debugging"
-                    },
                     {
                         "path": "/manuals/hot-reload",
                         "name": "Hot reloading"
@@ -496,6 +496,35 @@
                     }
                 ]
             },
+            {
+                "name": "DEBUGGING",
+                "items": [
+                    {
+                        "path": "/manuals/debugging-game-logic",
+                        "name": "Debugging game logic"
+                    },
+                    {
+                        "path": "/manuals/debugging-native-code",
+                        "name": "Debugging native code"
+                    },
+                    {
+                        "path": "/manuals/debugging-native-code-android",
+                        "name": "Debugging native code on Android"
+                    },
+                    {
+                        "path": "/manuals/debugging-native-code-ios",
+                        "name": "Debugging native code on iOS"
+                    },
+                    {
+                        "path": "/manuals/debugging-game-and-system-logs",
+                        "name": "Reading game and system logs"
+                    },
+                    {
+                        "path": "/manuals/profiling",
+                        "name": "Profiling"
+                    }
+                ]
+            },
             {
                 "name": "PLATFORMS",
                 "items": [
@@ -588,18 +617,6 @@
                     {
                         "path": "/manuals/extensions-manifest-merge-tool",
                         "name": "Manifest Merging"
-                    },
-                    {
-                        "path": "/manuals/extensions-debugging",
-                        "name": "Debugging tips"
-                    },
-                    {
-                        "path": "/manuals/extensions-debugging-android",
-                        "name": "Debugging on Android"
-                    },
-                    {
-                        "path": "/manuals/extensions-debugging-ios",
-                        "name": "Debugging on iOS"
                     }
                 ]
             },

docs/en/manuals/debugging-game-and-system-logs.md

@@ -0,0 +1,92 @@
+---
+title: Debugging - game and system logs
+brief: This manual explains how to read game and system logs.
+---
+
+# Game and system log
+
+The game log shows all of the output from the engine, native extensions and your game logic. The [print()](/ref/stable/base/#print:...) and [pprint()](/ref/stable/builtins/?q=pprint#pprint:v) commands can be used from your scripts and Lua modules to show information in the game log. You can use the functions in the [dmLog namespace](/ref/stable/dmLog/) to write to the game log from native extensions. The game log can be read from the editor, from a terminal window, using platform specific tools or from a log file.
+
+System logs are generated by the operating system and it can provide additional information that can help you pintpoint a problem. The system logs can contain stack traces for crashes and low memory warnings.
+
+:::important
+The game log will only show information in debug builds. The log will be completely empty in release builds.
+:::
+
+## Reading the game log from the editor
+
+When you run your game locally from the editor or connected to the [mobile dev app](/manuals/dev-app) all of the output will be shown in the console pane of the editor:
+
+![Editor 2](images/editor/editor2_overview.png)
+
+## Reading the game log from the terminal
+
+When you run a Defold game from the terminal the log will show in the terminal window itself. On Windows and Linux you type the name of the executable in the terminal to start the game. On macOS you need to launch the engine from within the .app file:
+
+```
+$ > ./mygame.app/Contenst/MacOS/mygame
+```
+
+## Reading game and system logs using platform specific tools
+
+### HTML5
+
+Logs can be read using the developer tools provided by most browsers.
+
+* [Chrome](https://developers.google.com/web/tools/chrome-devtools/console)
+* [Firefox](https://developer.mozilla.org/en-US/docs/Tools/Browser_Console)
+* [Edge](https://docs.microsoft.com/en-us/microsoft-edge/devtools-guide/console)
+* [Safari](https://support.apple.com/guide/safari-developer/log-messages-with-the-console-dev4e7dedc90/mac)
+
+### Android
+
+You can use the [Android Debug Bridge (ADB) tool](https://developer.android.com/studio/command-line/adb.html) to view the game and system log.
+
+  Once installed and setup, connect your device with USB, open a terminal and run:
+
+  ```txt
+  cd <path_to_android_sdk>/platform-tools/
+  adb logcat
+  ```
+
+  The device will then dump all the output to the current terminal, along with any prints from the game.
+
+  If you want to see only Defold application outputs use this command:
+
+  ```txt
+  cd <path_to_android_sdk>/platform-tools/
+  adb logcat -s defold
+  ```
+
+### iOS
+
+You can use the [Console tool](https://support.apple.com/guide/console/welcome/mac) to read game and system log. You can use the LLDB debugger to attach to a game running on device. To debug a game it needs to be signed with a “Apple Developer Provisioning Profile” that include the device you want to debug on. Bundle the game from the editor and supply the provisioning profile in the bundle dialog (bundling for iOS is only available on macOS).
+
+  To launch the game and attach the debugger you will need a tool called [ios-deploy](https://github.com/phonegap/ios-deploy). Install and debug your game by running the following in a terminal:
+
+  ```txt
+  ios-deploy --debug --bundle <path_to_game.app> # NOTE: not the .ipa file
+  ```
+
+  This will install the app on your device, start it and automatically attach a LLDB debugger to it. If you are new to LLDB, read [Getting Started with LLDB](https://developer.apple.com/library/content/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-basics.html).
+
+
+## Reading the game log from the log file
+
+If you enable the *Write Log* setting in "game.project", any game output will be written to disk, to a file called "log.txt". Here is how you extract the file if you run the game on device:
+
+iOS
+: Connect your device to a computer with macOS and Xcode installed.
+
+  Open Xcode and go to <kbd>Window ▸ Devices and Simulators</kbd>.
+
+  Select your device in the list, then select the relevant app in the *Installed Apps* list.
+
+  Click the cog icon below the list and select <kbd>Download Container...</kbd>.
+
+  ![download container](images/debugging/download_container.png){srcset="images/debugging/[email protected] 2x"}
+
+  Once the container has been extracted it will be shown in *Finder*. Right click the container and select <kbd>Show Package Content</kbd>. Locate the file "log.txt", which should be located in "AppData/Documents/".
+
+Android
+: The ability to extract the "log.txt" depends on OS version and manufacturer. Here is a short and simple step by step guide: https://stackoverflow.com/a/48077004/129360

docs/en/manuals/debugging-game-logic.md

@@ -0,0 +1,147 @@
+---
+title: Debugging in Defold
+brief: This manual explains the debugging facilities present in Defold.
+---
+
+# Debugging game logic
+
+Defold contains an integrated Lua debugger with an inspection facility. Together with the built-in [profiling tools](/manuals/profiling) it is a powerful tool that can help finding the cause of bugs in your game logic or help analyze performance issues.
+
+## Print and visual debugging
+
+The simplest way to debug your game in Defold is to use [print debugging](http://en.wikipedia.org/wiki/Debugging#Techniques). Use `print()` or [`pprint()`](/ref/builtins#pprint) statements to watch variables or indicate the flow of execution. If a game object without a script acts weird, you can just attach a script to it with the sole purpose of debugging. Using any of the printing functions will print to the *Console* view in the editor and to the [game log](/manuals/debugging-game-and-system-logs).
+
+In addition to printing, the engine can also draw debug text and straight lines on the screen. This is done by posting messages to the `@render` socket:
+
+```lua
+-- Draw value of "my_val" with debug text on the screen
+msg.post("@render:", "draw_text", { text = "My value: " .. my_val, position = vmath.vector3(200, 200, 0) })
+
+-- Draw debug line between player and enemy on the screen
+local start_p = go.get_position("player")
+local end_p = go.get_position("enemy")
+local color_red = vmath.vector4(1, 0, 0, 1)
+msg.post("@render:", "draw_line", { start_point = start_p, end_point = end_p, color = color_red })
+```
+
+The visual debug messages adds data to the rendering pipeline and is drawn as part of the regular render pipeline.
+
+* `"draw_line"` adds data that is rendered with the `render.draw_debug3d()` function in the render script.
+* `"draw_text"` is rendered with the "/builtins/fonts/system_font.font" that uses the "/builtins/fonts/system_font.material" material.
+
+Note that you probably want to update this data every frame so posting the messages in the `update()` function is a good idea.
+
+## Running the debugger
+
+To run the debugger, either <kbd>Debug ▸ Run with Debugger</kbd> which starts up the game with the debugger attached, or select <kbd>Debug ▸ Attach Debugger</kbd> to attach the debugger to an already running game.
+
+![overview](images/debugging/overview.png){srcset="images/debugging/[email protected] 2x"}
+
+As soon as the debugger is attached, you have control of the execution of the game through the debugger control buttons in the console, or through the <kbd>Debug</kbd> menu:
+
+Break
+: ![pause](images/debugging/pause.svg){width=60px .left}
+  Break execution of the game immediately. The game will break at its current point. You are now able to inspect the state of the game, advance the game step by step, or continue running it until the next breakpoint. The current point of execution is marked in the code editor:
+
+  ![script](images/debugging/script.png){srcset="images/debugging/[email protected] 2x"}
+
+Continue
+: ![play](images/debugging/play.svg){width=60px .left}
+  Continue running the game. The game code will continue to run until you either press pause or the execution hits a breakpoint that you have set. If execution breaks at a set breakpoint, the the execution point is marked in the code editor on top of the breakpoint marker:
+
+  ![break](images/debugging/break.png){srcset="images/debugging/[email protected] 2x"}
+
+Stop
+: ![stop](images/debugging/stop.svg){width=60px .left}
+  Stop the debugger. Pressing this button will immediately stop the debugger, detach it from the game and terminate the running game.
+
+Step Over
+: ![step over](images/debugging/step_over.svg){width=60px .left}
+  Advance execution of the program one step. If the execution involves running another Lua function, the execution _will not step into the function_ but continue running and stop on the next line below the function call. In this example, if the user presses "step over", the debugger will execute code and stop at the `end` statement below the line with the call to the function `nextspawn()`:
+
+  ![step](images/debugging/step.png){srcset="images/debugging/[email protected] 2x"}
+
+::: sidenote
+A line of Lua code does not correspond to a single expression. Stepping in the debugger moves ahead one expression at a time, meaning that currently you may have to hit the step button more than once to advance to the next line.
+:::
+
+Step Into
+: ![step in](images/debugging/step_in.svg){width=60px .left}
+  Advance execution of the program one step. If the execution involves running another Lua function, the execution _will step into the function_. Calling the function adds an entry to the call stack. You can click each entry in the call stack list to view the entry point and the content of all variables in that closure. Here, the user has stepped into the function `nextspawn()`:
+
+  ![step into](images/debugging/step_into.png){srcset="images/debugging/[email protected] 2x"}
+
+Step Out
+: ![step out](images/debugging/step_out.svg){width=60px .left}
+  Continue execution until it returns from the current function. If you have stepped execution into a function, pressing the button "step out" will continue execution until the function returns.
+
+Setting and clearing breakpoints
+: You can set an arbitrary number of breakpoints in your Lua code. When the game runs with the debugger attached, it will stop execution at the next breakpoint it encounters and wait for further interaction from you.
+
+  ![add breakpoint](images/debugging/add_breakpoint.png){srcset="images/debugging/[email protected] 2x"}
+
+  To set or clear a breakpoint, click in the column just right of the line numbers in the code editor. You can also select <kbd>Edit ▸ Toggle Breakpoint</kbd> from the menu.
+
+Evaluating Lua expressions
+: With the debugger attached and the game stopped at a breakpoint, a Lua runtime is available with the current context. Type Lua expressions in the bottom of the console and press <kbd>Enter</kbd> to evaluate them:
+
+  ![console](images/debugging/console.png){srcset="images/debugging/[email protected] 2x"}
+
+  It is currently not possible to modify variables through the evaluator.
+
+Detaching the debugger
+: Select <kbd>Debug ▸ Detach Debugger</kbd> to detach the debugger from the game. It will continue running immediately.
+
+## Extracting the log.txt file
+
+If you enable the *Write Log* setting in "game.project", any game output will be written to disk, to a file called "log.txt". Here is how you extract the file if you run the game on device:
+
+iOS
+: Connect your device to a computer with macOS and Xcode installed.
+
+  Open Xcode and go to <kbd>Window ▸ Devices and Simulators</kbd>.
+
+  Select your device in the list, then select the relevant app in the *Installed Apps* list.
+
+  Click the cog icon below the list and select <kbd>Download Container...</kbd>.
+
+  ![download container](images/debugging/download_container.png){srcset="images/debugging/[email protected] 2x"}
+
+  Once the container has been extracted it will be shown in *Finder*. Right click the container and select <kbd>Show Package Content</kbd>. Locate the file "log.txt", which should be located in "AppData/Documents/".
+
+Android
+: The ability to extract the "log.txt" depends on OS version and manufacturer. Here is a short and simple step by step guide: https://stackoverflow.com/a/48077004/129360
+
+## Lua debug library
+
+Lua comes with a debug library that is useful in some situations, particularly if you need to inspect the innards of your Lua environment. You can find more information about it here: http://www.lua.org/pil/contents.html#23.
+
+## Debugging checklist
+
+If you encounter an error or if your game does not behave like expected, here is a debugging checklist:
+
+1. Check the console output and verify that there are no runtime errors.
+
+2. Add `print` statements to your code to verify that the code is actually running.
+
+3. If it's not running, check that you have done the proper setup in the editor required for the code to run. Is the script added to the right game object? Have your script acquired input focus? Are the input-triggers correct? Is the shader code added to the material? Etc.
+
+4. If your code is depending on the values of variables (in an if-statement, for example), either `print` those values where they are used or checked, or inspect them with the debugger.
+
+Sometimes finding a bug can be a hard and time consuming process, requiring you to go through your code bit by bit, checking everything and narrowing down the faulty code and eliminating sources of error. This is best done by a method called "divide and conquer":
+
+1. Figure out which half (or less) of the code that must contain the bug.
+2. Again, figure out which half, of that half, must contain the bug.
+3. Continue narrowing down the code that must cause the bug until you find it.
+
+Happy hunting!
+
+## Debugging problems with physics
+
+If you have problems with physics and collisions aren't working as expected it is recommended to enable physics debugging. Check the *Debug* checkbox in the *Physics* section of the *game.project* file:
+
+![physics debug setting](images/debugging/physics_debug_setting.png)
+
+When this checkbox is enabled Defold will draw all collision shapes and contact points of collisions:
+
+![physics debug visualisation](images/debugging/physics_debug_visualisation.png)

docs/en/manuals/debugging-native-code-android.md

@@ -0,0 +1,83 @@
+---
+title: Debugging on Android
+brief: This manual describes how to debug a build running on an Android device.
+---
+
+# Debugging on Android
+
+Here we list some ways to debug your executable running on an Android device
+
+## Android Studio
+
+* Prepare the bundle by setting the `android.debuggable` option in `game.project`
+
+	![android.debuggable](images/extensions/debugging/android/game_project_debuggable.png)
+
+* Bundle the app in debug mode into a folder of choice.
+
+	![bundle_android](images/extensions/debugging/android/bundle_android.png)
+
+* Launch [Android Studio](https://developer.android.com/studio/)
+
+* Choose `Profile or debug APK`
+
+	![debug_apk](images/extensions/debugging/android/android_profile_or_debug.png)
+
+* Choose the apk bundle you just created
+
+	![select_apk](images/extensions/debugging/android/android_select_apk.png)
+
+* Select the main `.so` file, and make sure it has debug symbols
+
+	![select_so](images/extensions/debugging/android/android_missing_symbols.png)
+
+* If it doesn't, upload an unstripped `.so` file. (size is around 20mb)
+
+* Path mappings help you remap where the individual paths from where the executable was built (in the cloud) to an actual folder on your local drive.
+
+* Select the .so file, then add a mapping your local drive
+
+	![path_mapping1](images/extensions/debugging/android/path_mappings_android.png)
+
+	![path_mapping2](images/extensions/debugging/android/path_mappings_android2.png)
+
+* If you have access to the engine source, add a path mapping to that too
+
+		* make sure to checkout the version you are currently debugging
+
+			defold$ git checkout 1.2.148
+
+* Press `Apply changes`
+
+* You should now see the source mapped in your project
+
+	![source](images/extensions/debugging/android/source_mappings_android.png)
+
+* Add a breakpoint
+
+	![breakpoint](images/extensions/debugging/android/breakpoint_android.png)
+
+* Press `Run` -> `Debug "Appname"` and invoke the code you meant to break into
+
+	![breakpoint](images/extensions/debugging/android/callstack_variables_android.png)
+
+* You can now step in the callstack as well as inspect the variables
+
+
+## Notes
+
+### Native Extension job folder
+
+Currently, the workflow is a bit troublesome for development. This is because the job folder name
+is random for each build, making the path mapping invalid for each build.
+
+However, it works fine for a debugging session.
+
+The path mappings are stored in the <project>.iml file in the Android Studio project.
+
+It's possible to get the job folder from the executable
+
+	$ arm-linux-androideabi-readelf --string-dump=.debug_str build/armv7-android/libdmengine.so | grep /job
+
+The jobfolder is named like so `job1298751322870374150`, each time with a random number.
+

docs/en/manuals/debugging-native-code-ios.md

@@ -0,0 +1,136 @@
+---
+title: Debugging on iOS/macOS
+brief: This manual describes how to debug a build using XCode.
+---
+
+# Debugging on iOS/macOS
+
+Here we describe how to debug a build using [XCode](https://developer.apple.com/xcode/), Apple's preferred IDE for developing for macOS and iOS.
+
+## Xcode
+
+* Bundle the app by using bob, with the `--with-symbols` option
+
+		$ cd myproject
+		$ wget http://d.defold.com/archive/<sha1>/bob/bob.jar
+		$ java -jar bob.jar --platform armv7-darwin build --with-symbols debug --archive bundle -bo build/ios -mp <app>.mobileprovision --identity "iPhone Developer: Your Name (ID)"
+
+* Install the app, either with `XCode`, `iTunes` or [ios-deploy](https://github.com/ios-control/ios-deploy)
+
+		$ ios-deploy -b <AppName>.ipa
+
+* Get the `.dSYM` folder (i.e the debug symbols)
+
+	* If it's not using Native Extensions, you can download the `.dSYM` file from [d.defold.com](http://d.defold.com)
+
+	* If you are using a native extension, then the `.dSYM` folder is generated when you build with [bob.jar](https://www.defold.com/manuals/bob/). Only building is required (no archive or bundling):
+
+			$ cd myproject
+			$ unzip .internal/cache/arm64-ios/build.zip
+			$ mv dmengine.dSYM <AppName>.dSYM
+			$ mv <AppName>.dSYM/Contents/Resources/DWARF/dmengine <AppName>.dSYM/Contents/Resources/DWARF/<AppName>
+
+
+### Create Project
+
+To properly debug, we need to have a project, and the source code mapped.
+We're not using this project to build things, only debug.
+
+* Create new XCode project, choose the `Game` template
+
+	![project_template](images/extensions/debugging/ios/project_template.png)
+
+* Choose a name (e.g. `debug`) and the default settings
+
+* Choose a folder to save the project into
+
+* Add your code to the app
+
+	![add_files](images/extensions/debugging/ios/add_files.png)
+
+* Make sure the "Copy items if needed" is unchecked.
+
+	![add_source](images/extensions/debugging/ios/add_source.png)
+
+* This is the end result
+
+	![added_source](images/extensions/debugging/ios/added_source.png)
+
+
+* Disable the `Build` step
+
+	![edit_scheme](images/extensions/debugging/ios/edit_scheme.png)
+
+	![disable_build](images/extensions/debugging/ios/disable_build.png)
+
+* Set the `Deployment target` version so it's now larger than your device iOS version
+
+	![deployment_version](images/extensions/debugging/ios/deployment_version.png)
+
+* Select the target device
+
+	![select_device](images/extensions/debugging/ios/select_device.png)
+
+
+### Launch the debugger
+
+You have a few options to debug an app
+
+1. Either choose `Debug` -> `Attach to process...` and select the app from there
+
+1. Or choose the `Attach to process by PID or Process name`
+
+	![select_device](images/extensions/debugging/ios/attach_to_process_name.png)
+
+	1. Start the app on the device
+
+1. In `Edit Scheme` add the <AppName>.app folder as the executable
+
+### Debug symbols
+
+**To use lldb, the execution must be paused**
+
+* Add the `.dSYM` path to lldb
+
+		(lldb) add-dsym <PathTo.dSYM>
+
+	![add_dsym](images/extensions/debugging/ios/add_dsym.png)
+
+* Verify that `lldb` read the symbols successfully
+
+		(lldb) image list <AppName>
+
+### Path mappings
+
+* Add the engine source (change accordingly for your need)
+
+		(lldb) settings set target.source-map /Users/builder/ci/builds/engine-ios-64-master/build /Users/mathiaswesterdahl/work/defold
+		(lldb) settings append target.source-map /private/var/folders/m5/bcw7ykhd6vq9lwjzq1mkp8j00000gn/T/job4836347589046353012/upload/videoplayer/src /Users/mathiaswesterdahl/work/projects/extension-videoplayer-native/videoplayer/src
+
+	* It's possible to get the job folder from the executable.
+	The jobfolder is named like so `job1298751322870374150`, each time with a random number.
+
+			$ dsymutil -dump-debug-map <executable> 2>&1 >/dev/null | grep /job
+
+* Verify the source mappings
+
+		(lldb) settings show target.source-map
+
+You can check what source file a symbol was originating from using
+
+	(lldb) image lookup -va <SymbolName>
+
+
+### Breakpoints
+
+* Open a file in the project view, and set a breakpoint
+
+	![breakpoint](images/extensions/debugging/ios/breakpoint.png)
+
+## Notes
+
+### Check UUID of binary
+
+In order for the debugger to accept the `.dSYM` folder, the UUID need to match the UUID of the executable being debugged. You can check the UUID like so:
+
+	$ dwarfdump -u <PathToBinary>

docs/en/manuals/debugging-native-code.md

@@ -0,0 +1,135 @@
+---
+title: Debugging native code in Defold
+brief: This manual explains how to debug native code in Defold.
+---
+
+# Debugging native code
+
+Defold is well tested and should very rarely crash under normal circumstances. It is however impossible to guarantee that it will never crash, especially if your game uses native extensions. If you run into problems with crashes or native code that doesn't behave as expected there are a number of different ways forward:
+
+* Use a debugger to step through the code
+* Use print debugging
+* Analyze a crash log
+* Symbolicate a callstack
+
+* If Defold crashes it will store information about the crash that can be used to help pinpoint what went wrong.
+* You can also [read game and system logs](/manuals/game-and-system-logs) to help you figure out what went wrong.
+
+## Use a debugger
+
+The most common way is to run the code via a `debugger`. It let's you step through the code, set `breakpoints` and it will stop the execution if you get a crash.
+
+There are several debuggers for each platform.
+
+* Visual studio - Windows
+* VSCode - Windows, macOS, Linux
+* Android Studio - Windows, macOS, Linux
+* XCode - macOS
+* WinDBG - Windows
+* lldb / gdb - macOS, Linux, (Windows)
+* ios-deploy - macOS
+
+Each tool can debug certain platforms:
+
+* Visual studio - Windows + platforms supporting gdbserver (E.g. Linux/Android)
+* VSCode - Windows, macOS (lldb), Linux (lldb/gdb) + platforms supporting gdbserver
+* XCode -  macOS, iOS ([learn more](/manuals/debugging-native-code-ios))
+* Android Studio - Android ([learn more](/manuals/debugging-native-code-android))
+* WinDBG - Windows
+* lldb/gdb - macOS, Linux, (iOS)
+* ios-deploy - iOS (via lldb)
+
+
+## Use print debugging
+
+The simplest way to debug your native code is to use [print debugging](http://en.wikipedia.org/wiki/Debugging#Techniques). Use the functions in the [dmLog namespace](/ref/stable/dmLog/) to watch variables or indicate the flow of execution. Using any of the log functions will print to the *Console* view in the editor and to the [game log](/manuals/debugging-game-and-system-logs).
+
+
+## Analyze a crash log
+
+The Defold engine saves a `_crash` file if it does a hard crash. The crash file will contain information about the system as well as the crash.
+
+You can use the [crash module](https://www.defold.com/ref/crash/) to read this file in the subsequent session. It is recommended that you read the file, gather the information, print it to the console and send it to an [analytics services](/tags/stars/analytics/) that supports collection of crash logs.
+
+### Getting the crash log from a device
+
+If a crash happens on a mobile device you can chose to download the crash file to your own computer and parse it locally.
+
+#### Android
+
+The [game log output](/manuals/debugging-game-and-system-logs) will write where the crash file is located (it varies from device to device and application to application). If the app is [debuggable](/manuals/project-settings/#android), you can get the crash log using the [Android Debug Bridge (ADB) tool](https://developer.android.com/studio/command-line/adb.html) and the `adb shell` command:
+
+```
+	$ adb shell "run-as com.defold.example sh -c 'cat /data/data/com.defold.example/files/_crash'" > ./_crash
+```
+
+#### iOS
+
+In iTunes, you can view/download an apps container.
+
+In the `XCode -> Devices` window, you can also select the crash logs
+
+
+### Symbolicate a callstack
+
+If you get a callstack from either a `_crash` file or a [log file](/manuals/debugging-game-and-system-logs), you can symbolicate it. This means translating each address in the callstack into a filename and line number, which in turn helps when finding out the root cause.
+
+#### Get correct engine
+
+It is important that you match the correct engine with the callstack. Otherwise it's very likely to send you debugging the incorrect things.
+
+Also, if you are building with native extensions, be sure to add the flag [--with-symbols](https://www.defold.com/manuals/bob/) so that you get all the needed data from the build server. For instance, in the `build.zip` you'll find the `dmengine.dSYM` folder for iOS/macOS builds.
+
+Android/Linux executables already contain the debug symbols.
+
+Also, you should keep an unstripped version of the engine. This allows for the best symbolication of the callstack.
+
+#### Android
+
+1. Get it from your build folder
+
+	$ ls <project>/build/<platform>/[lib]dmengine[.exe|.so]
+
+1. Unzip to a folder:
+
+	$ unzip dmengine.apk -d dmengine_1_2_105
+
+1. Find the callstack address
+
+	E.g. in the non symbolicated callstack on Crash Analytics, it could look like this
+
+	#00 pc 00257224 libmy_game_name.so
+
+	Where *00257224* is the address
+
+1. Resolve the address
+
+    $ arm-linux-androideabi-addr2line -C -f -e dmengine_1_2_105/lib/armeabi-v7a/libdmengine.so _address_
+
+Note: If you get hold of a stack trace from the [Android logs](/manuals/debugging-game-and-system-logs), you might be able to symbolicate it using [ndk-stack](https://developer.android.com/ndk/guides/ndk-stack.html)
+
+#### iOS
+
+1. If you are using Native Extensions, the server can provide the symbols (.dSYM) for you (pass `--with-symbols` to bob.jar)
+
+	$ unzip <project>/build/arm64-darwin/build.zip
+	# it will produce a Contents/Resources/DWARF/dmengine
+
+1. If you're not using Native Extensions, download the vanilla symbols:
+
+	$ wget http://d.defold.com/archive/<sha1>/engine/arm64-darwin/dmengine.dSYM
+
+1. Symbolicate using load address
+
+	For some reason, simply putting the address from the callstack doesn't work (i.e. load address 0x0)
+
+		$ atos -arch arm64 -o Contents/Resources/DWARF/dmengine 0x1492c4
+
+	# Neither does specifying the load address directly
+
+		$ atos -arch arm64 -o MyApp.dSYM/Contents/Resources/DWARF/MyApp -l0x100000000 0x1492c4
+
+	Adding the load address to the address works:
+
+		$ atos -arch arm64 -o MyApp.dSYM/Contents/Resources/DWARF/MyApp 0x1001492c4
+		dmCrash::OnCrash(int) (in MyApp) (backtrace_execinfo.cpp:27)

docs/en/manuals/debugging.md

@@ -5,175 +5,7 @@ brief: This manual explains the debugging facilities present in Defold.
 
 # Debugging
 
-Defold contains an integrated Lua debugger with an inspection facility. Together with the built-in [profiling tools](/manuals/profiling) it is a powerful tool that can help finding the root cause of bugs or performance issues.
+Defold contains an integrated Lua debugger with an inspection facility. Together with the built-in [profiling tools](/manuals/profiling) it is a powerful tool that can help finding the cause of bugs in your game logic or help analyze performance issues. Defold also provides crash logs for the rare occasions when the engine itself crashes.
 
-## Print and visual debugging
-
-The simplest way to debug your game in Defold is to use [print debugging](http://en.wikipedia.org/wiki/Debugging#Techniques). The technique is simply to use `print()` or [`pprint()`](/ref/builtins#pprint) statements to watch variables or indicate the flow of execution. If a game object without a script acts weird, you can just attach a script to it with the sole purpose of debugging. Using any of the printing functions will print to the *Console* view in the editor.  In addition to printing, the engine can also draw debug text and straight lines on the screen. This is done by posting messages to the `@render` socket:
-
-```lua
--- Draw value of "my_val" with debug text on the screen
-msg.post("@render:", "draw_text", { text = "My value: " .. my_val, position = vmath.vector3(200, 200, 0) })
-
--- Draw debug line between player and enemy on the screen
-local start_p = go.get_position("player")
-local end_p = go.get_position("enemy")
-local color_red = vmath.vector4(1, 0, 0, 1)
-msg.post("@render:", "draw_line", { start_point = start_p, end_point = end_p, color = color_red })
-```
-
-The visual debug messages adds data to the rendering pipeline and is drawn as part of the regular render pipeline.
-
-* `"draw_line"` adds data that is rendered with the `render.draw_debug3d()` function in the render script.
-* `"draw_text"` is rendered with the "/builtins/fonts/system_font.font" that uses the "/builtins/fonts/system_font.material" material.
-
-Note that you probably want to update this data every frame so posting the messages in the `update()` function is a good idea.
-
-## Running the debugger
-
-To run the debugger, either <kbd>Debug ▸ Run with Debugger</kbd> which starts up the game with the debugger attached, or select <kbd>Debug ▸ Attach Debugger</kbd> to attach the debugger to an already running game.
-
-![overview](images/debugging/overview.png){srcset="images/debugging/[email protected] 2x"}
-
-As soon as the debugger is attached, you have control of the execution of the game through the debugger control buttons in the console, or through the <kbd>Debug</kbd> menu:
-
-Break
-: ![pause](images/debugging/pause.svg){width=60px .left}
-  Break execution of the game immediately. The game will break at its current point. You are now able to inspect the state of the game, advance the game step by step, or continue running it until the next breakpoint. The current point of execution is marked in the code editor:
-
-  ![script](images/debugging/script.png){srcset="images/debugging/[email protected] 2x"}
-
-Continue
-: ![play](images/debugging/play.svg){width=60px .left}
-  Continue running the game. The game code will continue to run until you either press pause or the execution hits a breakpoint that you have set. If execution breaks at a set breakpoint, the the execution point is marked in the code editor on top of the breakpoint marker:
-
-  ![break](images/debugging/break.png){srcset="images/debugging/[email protected] 2x"}
-
-Stop
-: ![stop](images/debugging/stop.svg){width=60px .left}
-  Stop the debugger. Pressing this button will immediately stop the debugger, detach it from the game and terminate the running game.
-
-Step Over
-: ![step over](images/debugging/step_over.svg){width=60px .left}
-  Advance execution of the program one step. If the execution involves running another Lua function, the execution _will not step into the function_ but continue running and stop on the next line below the function call. In this example, if the user presses "step over", the debugger will execute code and stop at the `end` statement below the line with the call to the function `nextspawn()`:
-
-  ![step](images/debugging/step.png){srcset="images/debugging/[email protected] 2x"}
-
-::: sidenote
-A line of Lua code does not correspond to a single expression. Stepping in the debugger moves ahead one expression at a time, meaning that currently you may have to hit the step button more than once to advance to the next line.
-:::
-
-Step Into
-: ![step in](images/debugging/step_in.svg){width=60px .left}
-  Advance execution of the program one step. If the execution involves running another Lua function, the execution _will step into the function_. Calling the function adds an entry to the call stack. You can click each entry in the call stack list to view the entry point and the content of all variables in that closure. Here, the user has stepped into the function `nextspawn()`:
-
-  ![step into](images/debugging/step_into.png){srcset="images/debugging/[email protected] 2x"}
-
-Step Out
-: ![step out](images/debugging/step_out.svg){width=60px .left}
-  Continue execution until it returns from the current function. If you have stepped execution into a function, pressing the button "step out" will continue execution until the function returns.
-
-Setting and clearing breakpoints
-: You can set an arbitrary number of breakpoints in your Lua code. When the game runs with the debugger attached, it will stop execution at the next breakpoint it encounters and wait for further interaction from you.
-
-  ![add breakpoint](images/debugging/add_breakpoint.png){srcset="images/debugging/[email protected] 2x"}
-
-  To set or clear a breakpoint, click in the column just right of the line numbers in the code editor. You can also select <kbd>Edit ▸ Toggle Breakpoint</kbd> from the menu.
-
-Evaluating Lua expressions
-: With the debugger attached and the game stopped at a breakpoint, a Lua runtime is available with the current context. Type Lua expressions in the bottom of the console and press <kbd>Enter</kbd> to evaluate them:
-
-  ![console](images/debugging/console.png){srcset="images/debugging/[email protected] 2x"}
-
-  It is currently not possible to modify variables through the evaluator.
-
-Detaching the debugger
-: Select <kbd>Debug ▸ Detach Debugger</kbd> to detach the debugger from the game. It will continue running immediately.
-
-## Debugging on mobile devices
-
-Some issues can be hard to debug with the editor debugger. Diagnosing problems such as native crashes and out of memory issues may need you to connect to the devices with USB cable and make use of a terminal.
-
-Android
-: Once your game is launched on your Android device, you can view all program output and crash stacktraces using the "adb" tool, which is part of the Android SDK. Documentation for "adb" and installation links can be found here: https://developer.android.com/studio/command-line/adb.html
-
-  Once installed and setup, connect your device with USB, open a terminal and run:
-
-  ```txt
-  cd <path_to_android_sdk>/platform-tools/
-  adb logcat
-  ```
-
-  The device will then dump all the output to the current terminal, along with any prints from the game.
-
-  If you want to see only Defold application outputs use next command:
-  ```txt
-  cd <path_to_android_sdk>/platform-tools/
-  adb logcat -s defold
-  ```
-
-iOS
-: On iOS you can attach the LLDB debugger to a game running on device. To debug a game it needs to be signed with a “Apple Developer Provisioning Profile” that include the device you want to debug on. Bundle the game from the editor and supply the provisioning profile in the bundle dialog (bundling for iOS is only available on macOS).
-
-  To launch the game and attach the debugger you will need a tool called [ios-deploy](https://github.com/phonegap/ios-deploy). Install and debug your game by running the following in a terminal:
-
-  ```txt
-  ios-deploy --debug --bundle <path_to_game.app> # NOTE: not the .ipa file
-  ```
-
-  This will install the app on your device, start it and automatically attach a LLDB debugger to it. If you are new to LLDB, read [Getting Started with LLDB](https://developer.apple.com/library/content/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-basics.html).
-
-
-## Extracting the log.txt file
-
-If you enable the *Write Log* setting in "game.project", any game output will be written to disk, to a file called "log.txt". Here is how you extract the file if you run the game on device:
-
-iOS
-: Connect your device to a computer with macOS and Xcode installed.
-
-  Open Xcode and go to <kbd>Window ▸ Devices and Simulators</kbd>.
-
-  Select your device in the list, then select the relevant app in the *Installed Apps* list.
-
-  Click the cog icon below the list and select <kbd>Download Container...</kbd>.
-
-  ![download container](images/debugging/download_container.png){srcset="images/debugging/[email protected] 2x"}
-
-  Once the container has been extracted it will be shown in *Finder*. Right click the container and select <kbd>Show Package Content</kbd>. Locate the file "log.txt", which should be located in "AppData/Documents/".
-
-Android
-: The ability to extract the "log.txt" depends on OS version and manufacturer. Here is a short and simple step by step guide: https://stackoverflow.com/a/48077004/129360
-
-## Lua debug library
-
-Lua comes with a debug library that is useful in some situations, particularly if you need to inspect the innards of your Lua environment. You can find more information about it here: http://www.lua.org/pil/contents.html#23.
-
-## Debugging checklist
-
-If you encounter an error or if your game does not behave like expected, here is a debugging checklist:
-
-1. Check the console output and verify that there are no runtime errors.
-
-2. Add `print` statements to your code to verify that the code is actually running.
-
-3. If it's not running, check that you have done the proper setup in the editor required for the code to run. Is the script added to the right game object? Have your script acquired input focus? Are the input-triggers correct? Is the shader code added to the material? Etc.
-
-4. If your code is depending on the values of variables (in an if-statement, for example), either `print` those values where they are used or checked, or inspect them with the debugger.
-
-Sometimes finding a bug can be a hard and time consuming process, requiring you to go through your code bit by bit, checking everything and narrowing down the faulty code and eliminating sources of error. This is best done by a method called "divide and conquer":
-
-1. Figure out which half (or less) of the code that must contain the bug.
-2. Again, figure out which half, of that half, must contain the bug.
-3. Continue narrowing down the code that must cause the bug until you find it.
-
-Happy hunting!
-
-## Debugging problems with physics
-
-If you have problems with physics and collisions aren't working as expected it is recommended to enable physics debugging. Check the *Debug* checkbox in the *Physics* section of the *game.project* file:
-
-![physics debug setting](images/debugging/physics_debug_setting.png)
-
-When this checkbox is enabled Defold will draw all collision shapes and contact points of collisions:
-
-![physics debug visualisation](images/debugging/physics_debug_visualisation.png)
+* Learn more about [debugging your game logic](/manuals/debugging-game-logic).
+* Learn more about [debugging native code](/manuals/debugging-native-code).

docs/en/manuals/extensions-debugging-android.md

@@ -3,81 +3,4 @@ title: Debugging on Android
 brief: This manual describes how to debug a build running on an Android device.
 ---
 
-# Debugging on Android
-
-Here we list some ways to debug your executable running on an Android device
-
-## Android Studio
-
-* Prepare the bundle by setting the `android.debuggable` option in `game.project`
-
-	![android.debuggable](images/extensions/debugging/android/game_project_debuggable.png)
-
-* Bundle the app in debug mode into a folder of choice.
-
-	![bundle_android](images/extensions/debugging/android/bundle_android.png)
-
-* Launch [Android Studio](https://developer.android.com/studio/)
-
-* Choose `Profile or debug APK`
-
-	![debug_apk](images/extensions/debugging/android/android_profile_or_debug.png)
-
-* Choose the apk bundle you just created
-
-	![select_apk](images/extensions/debugging/android/android_select_apk.png)
-
-* Select the main `.so` file, and make sure it has debug symbols
-
-	![select_so](images/extensions/debugging/android/android_missing_symbols.png)
-
-* If it doesn't, upload an unstripped `.so` file. (size is around 20mb)
-
-* Path mappings help you remap where the individual paths from where the executable was built (in the cloud) to an actual folder on your local drive.
-
-* Select the .so file, then add a mapping your local drive
-
-	![path_mapping1](images/extensions/debugging/android/path_mappings_android.png)
-
-	![path_mapping2](images/extensions/debugging/android/path_mappings_android2.png)
-
-* If you have access to the engine source, add a path mapping to that too
-
-		* make sure to checkout the version you are currently debugging
-
-			defold$ git checkout 1.2.148
-
-* Press `Apply changes`
-
-* You should now see the source mapped in your project
-
-	![source](images/extensions/debugging/android/source_mappings_android.png)
-
-* Add a breakpoint
-
-	![breakpoint](images/extensions/debugging/android/breakpoint_android.png)
-
-* Press `Run` -> `Debug "Appname"` and invoke the code you meant to break into
-
-	![breakpoint](images/extensions/debugging/android/callstack_variables_android.png)
-
-* You can now step in the callstack as well as inspect the variables
-
-
-## Notes
-
-### Native Extension job folder
-
-Currently, the workflow is a bit troublesome for development. This is because the job folder name
-is random for each build, making the path mapping invalid for each build.
-
-However, it works fine for a debugging session.
-
-The path mappings are stored in the <project>.iml file in the Android Studio project.
-
-It's possible to get the job folder from the executable
-
-	$ arm-linux-androideabi-readelf --string-dump=.debug_str build/armv7-android/libdmengine.so | grep /job
-
-The jobfolder is named like so `job1298751322870374150`, each time with a random number.
-
+Moved to [Debugging Native Code on Android](/manuals/debugging-native-code-android)

docs/en/manuals/extensions-debugging-ios.md

@@ -3,134 +3,4 @@ title: Debugging on iOS/macOS
 brief: This manual describes how to debug a build using XCode.
 ---
 
-# Debugging on iOS/macOS
-
-Here we describe how to debug a build using [XCode](https://developer.apple.com/xcode/), Apple's preferred IDE for developing for macOS and iOS.
-
-## Xcode
-
-* Bundle the app by using bob, with the `--with-symbols` option
-
-		$ cd myproject
-		$ wget http://d.defold.com/archive/<sha1>/bob/bob.jar
-		$ java -jar bob.jar --platform armv7-darwin build --with-symbols debug --archive bundle -bo build/ios -mp <app>.mobileprovision --identity "iPhone Developer: Your Name (ID)"
-
-* Install the app, either with `XCode`, `iTunes` or [ios-deploy](https://github.com/ios-control/ios-deploy)
-
-		$ ios-deploy -b <AppName>.ipa
-
-* Get the `.dSYM` folder (i.e the debug symbols)
-
-	* If it's not using Native Extensions, you can download the `.dSYM` file from [d.defold.com](http://d.defold.com)
-
-	* If you are using a native extension, then the `.dSYM` folder is generated when you build with [bob.jar](https://www.defold.com/manuals/bob/). Only building is required (no archive or bundling):
-
-			$ cd myproject
-			$ unzip .internal/cache/arm64-ios/build.zip
-			$ mv dmengine.dSYM <AppName>.dSYM
-			$ mv <AppName>.dSYM/Contents/Resources/DWARF/dmengine <AppName>.dSYM/Contents/Resources/DWARF/<AppName>
-
-
-### Create Project
-
-To properly debug, we need to have a project, and the source code mapped.
-We're not using this project to build things, only debug.
-
-* Create new XCode project, choose the `Game` template
-
-	![project_template](images/extensions/debugging/ios/project_template.png)
-
-* Choose a name (e.g. `debug`) and the default settings
-
-* Choose a folder to save the project into
-
-* Add your code to the app
-
-	![add_files](images/extensions/debugging/ios/add_files.png)
-
-* Make sure the "Copy items if needed" is unchecked.
-
-	![add_source](images/extensions/debugging/ios/add_source.png)
-
-* This is the end result
-
-	![added_source](images/extensions/debugging/ios/added_source.png)
-
-
-* Disable the `Build` step
-
-	![edit_scheme](images/extensions/debugging/ios/edit_scheme.png)
-
-	![disable_build](images/extensions/debugging/ios/disable_build.png)
-
-* Set the `Deployment target` version so it's now larger than your device iOS version
-
-	![deployment_version](images/extensions/debugging/ios/deployment_version.png)
-
-* Select the target device
-
-	![select_device](images/extensions/debugging/ios/select_device.png)
-
-
-### Launch the debugger
-
-You have a few options to debug an app
-
-1. Either choose `Debug` -> `Attach to process...` and select the app from there
-
-1. Or choose the `Attach to process by PID or Process name`
-
-	![select_device](images/extensions/debugging/ios/attach_to_process_name.png)
-
-	1. Start the app on the device
-
-1. In `Edit Scheme` add the <AppName>.app folder as the executable
-
-### Debug symbols
-
-**To use lldb, the execution must be paused**
-
-* Add the `.dSYM` path to lldb
-
-		(lldb) add-dsym <PathTo.dSYM>
-
-	![add_dsym](images/extensions/debugging/ios/add_dsym.png)
-
-* Verify that `lldb` read the symbols successfully
-
-		(lldb) image list <AppName>
-
-### Path mappings
-
-* Add the engine source (change accordingly for your need)
-
-		(lldb) settings set target.source-map /Users/builder/ci/builds/engine-ios-64-master/build /Users/mathiaswesterdahl/work/defold
-		(lldb) settings append target.source-map /private/var/folders/m5/bcw7ykhd6vq9lwjzq1mkp8j00000gn/T/job4836347589046353012/upload/videoplayer/src /Users/mathiaswesterdahl/work/projects/extension-videoplayer-native/videoplayer/src
-
-	* It's possible to get the job folder from the executable.
-	The jobfolder is named like so `job1298751322870374150`, each time with a random number.
-
-			$ dsymutil -dump-debug-map <executable> 2>&1 >/dev/null | grep /job
-
-* Verify the source mappings
-
-		(lldb) settings show target.source-map
-
-You can check what source file a symbol was originating from using
-
-	(lldb) image lookup -va <SymbolName>
-
-
-### Breakpoints
-
-* Open a file in the project view, and set a breakpoint
-
-	![breakpoint](images/extensions/debugging/ios/breakpoint.png)
-
-## Notes
-
-### Check UUID of binary
-
-In order for the debugger to accept the `.dSYM` folder, the UUID need to match the UUID of the executable being debugged. You can check the UUID like so:
-
-	$ dwarfdump -u <PathToBinary>
+Moved to [Debugging Native Code on iOS](/manuals/debugging-native-code-ios).

docs/en/manuals/extensions-debugging.md

@@ -3,156 +3,4 @@ title: Debugging extensions
 brief: This manual describes some ways to debug an application containing native extensions.
 ---
 
-# Debugging extensions
-
-When you develop a native extension you typically run into either problems when compiling the extension on the build server or when the extension code in an application.
-
-## Debugging build problems
-
-When a native extension fails to build the console usually shows all of the errors generated on the build server. You can see what kind of error it is and in which file and line number. The entire build log is also stored in a file `log.txt` in your build folder.
-
-## Debugging run-time problems
-
-When you get a particularly troublesome issue in your code, there are several ways to find the root cause.
-
-* Using a debugger
-* Using print debugging
-* Analyzing a crash log
-* Symbolicating a callstack
-
-### Using a debugger
-
-The most common way is to run the code via a `debugger`. It let's you step through the code, set `breakpoints` and it will stop the execution if you get a crash.
-
-There are several debuggers around for each platform.
-
-* Visual studio - Windows
-* VSCode - Windows, macOS, Linux
-* Android Studio - Windows, macOS, Linux
-* XCode - macOS
-* WinDBG - Windows
-* lldb / gdb - macOS, Linux, (Windows)
-* ios-deploy - macOS
-
-And each tool can debug certain platforms:
-
-* Visual studio - Windows + platforms supporting gdbserver (E.g. Linux/Android)
-* VSCode - Windows, macOS (lldb), Linux (lldb/gdb) + platforms supporting gdbserver
-* XCode -  macOS, iOS
-* Android Studio - Android
-* WinDBG - Windows
-* lldb/gdb - macOS, Linux, (iOS)
-* ios-deploy - iOS (via lldb)
-
-
-### Print debugging
-
-In certain cases, one might want to add `printf()` statements to the code. Afterwards, you can get the logs from your device and analyze them.
-
-Note that Defold by default only prints using dmLog* functions in the debug build.
-
-#### [Android](/manuals/extensions-debugging-android)
-
-On Android, the simplest way to get the log is to run `adb` in the terminal. You can also see the `console` inside Android Studio, which is the same thing.
-
-If you get hold of a stack trace from the Android logs, you might be able to symbolicate it using [ndk-stack](https://developer.android.com/ndk/guides/ndk-stack.html)
-
-#### [iOS](/manuals/extensions-debugging-ios)
-
-On iOS, you need to open either iTunes or XCode to view the device logs.
-
-
-### Defold Crash Log
-
-The Defold engine saves a `_crash` file when it does a hard crash. It will contain information about the system as well as the crash.
-
-You can use the [crash module](https://www.defold.com/ref/crash/) to read this file in the subsequent session.
-
-You are adviced to read the file, gather information and send it to a server of choice to aggregate the data.
-
-
-#### Getting the crash log from a device
-
-##### Android
-
-The adb output says where it is located (different location on different devices)
-
-If the app is [debuggable](https://www.defold.com/manuals/project-settings/#android), you can get the crash log like so:
-
-```
-	$ adb shell "run-as com.defold.adtest sh -c 'cat /data/data/com.defold.adtest/files/_crash'" > ./_crash
-```
-
-##### iOS
-
-In iTunes, you can view/download an apps container.
-
-In the `XCode -> Devices` window, you can also select the crash logs
-
-
-### Symbolication
-
-If you get a callstack from either a `_crash` file or a log file, you can start symbolicate it.
-This means translating each address in the callstack into a filename and line number, which in turn helps
-when finding out the root cause.
-
-#### Get correct engine
-
-It is important that you match the correct engine with the callstack.
-Otherwize it's very likely to send you debugging the incorrect things.
-
-Also, if you are building with native extensions, be sure to add the flag [--with-symbols](https://www.defold.com/manuals/bob/)
-so that you get all the needed data from the build server. For instance, in the `build.zip` you'll find the `dmengine.dSYM` folder for iOS/macOS builds.
-
-Android/Linux executables already contain the debug symbols.
-
-Also, you should keep an unstripped version of the engine.
-This allows for the best symbolication of the callstack.
-
-#### Android
-
-1. Get it from your build folder
-
-	$ ls <project>/build/<platform>/[lib]dmengine[.exe|.so]
-
-1. Unzip to a folder:
-
-	$ unzip dmengine.apk -d dmengine_1_2_105
-
-1. Find the callstack address
-
-	E.g. in the non symbolicated callstack on Crash Analytics, it could look like this
-
-	#00 pc 00257224 libmy_game_name.so
-
-	Where *00257224* is the address
-
-1. Resolve the address
-
-    $ arm-linux-androideabi-addr2line -C -f -e dmengine_1_2_105/lib/armeabi-v7a/libdmengine.so _address_
-
-#### iOS
-
-1. If you are using Native Extensions, the server can provide the symbols (.dSYM) for you (pass "--with-symbols" to bob.jar)
-
-	$ unzip <project>/build/arm64-darwin/build.zip
-	# it will produce a Contents/Resources/DWARF/dmengine
-
-1. If you're not using Native Extensions, download the vanilla symbols:
-
-	$ wget http://d.defold.com/archive/<sha1>/engine/arm64-darwin/dmengine.dSYM
-
-1. Symbolicate using load address
-
-	For some reason, simply putting the address from the callstack doesn't work (i.e. load address 0x0)
-
-		$ atos -arch arm64 -o Contents/Resources/DWARF/dmengine 0x1492c4
-
-	# Neither does specifying the load address directly
-
-		$ atos -arch arm64 -o MyApp.dSYM/Contents/Resources/DWARF/MyApp -l0x100000000 0x1492c4
-
-	Adding the load address to the address works:
-
-		$ atos -arch arm64 -o MyApp.dSYM/Contents/Resources/DWARF/MyApp 0x1001492c4
-		dmCrash::OnCrash(int) (in MyApp) (backtrace_execinfo.cpp:27)
+Refer to the [Debugging Native Code manual](/manuals/debugging-native-code) to learn more.