| 1 | |
| 2 |
|
| 3 | ============================================
|
| 4 | Debugging advice for Linux Kernel developers
|
| 5 | ============================================
|
| 6 |
|
| 7 | general guides
|
| 8 | --------------
|
| 9 |
|
| 10 | .. toctree::
|
| 11 | :maxdepth: 1
|
| 12 |
|
| 13 | driver_development_debugging_guide
|
| 14 | gdb-kernel-debugging
|
| 15 | kgdb
|
| 16 | userspace_debugging_guide
|
| 17 |
|
| 18 | subsystem specific guides
|
| 19 | -------------------------
|
| 20 |
|
| 21 | .. toctree::
|
| 22 | :maxdepth: 1
|
| 23 |
|
| 24 | media_specific_debugging_guide
|
| 25 |
|
| 26 | General debugging advice
|
| 27 | ========================
|
| 28 |
|
| 29 | Depending on the issue, a different set of tools is available to track down the
|
| 30 | problem or even to realize whether there is one in the first place.
|
| 31 |
|
| 32 | As a first step you have to figure out what kind of issue you want to debug.
|
| 33 | Depending on the answer, your methodology and choice of tools may vary.
|
| 34 |
|
| 35 | Do I need to debug with limited access?
|
| 36 | ---------------------------------------
|
| 37 |
|
| 38 | Do you have limited access to the machine or are you unable to stop the running
|
| 39 | execution?
|
| 40 |
|
| 41 | In this case your debugging capability depends on built-in debugging support of
|
| 42 | provided distribution kernel.
|
| 43 | The :doc:`/process/debugging/userspace_debugging_guide` provides a brief
|
| 44 | overview over a range of possible debugging tools in that situation. You can
|
| 45 | check the capability of your kernel, in most cases, by looking into config file
|
| 46 | within the /boot directory.
|
| 47 |
|
| 48 | Do I have root access to the system?
|
| 49 | ------------------------------------
|
| 50 |
|
| 51 | Are you easily able to replace the module in question or to install a new
|
| 52 | kernel?
|
| 53 |
|
| 54 | In that case your range of available tools is a lot bigger, you can find the
|
| 55 | tools in the :doc:`/process/debugging/driver_development_debugging_guide`.
|
| 56 |
|
| 57 | Is timing a factor?
|
| 58 | -------------------
|
| 59 |
|
| 60 | It is important to understand if the problem you want to debug manifests itself
|
| 61 | consistently (i.e. given a set of inputs you always get the same, incorrect
|
| 62 | output), or inconsistently. If it manifests itself inconsistently, some timing
|
| 63 | factor might be at play. If inserting delays into the code does change the
|
| 64 | behavior, then quite likely timing is a factor.
|
| 65 |
|
| 66 | When timing does alter the outcome of the code execution using a simple
|
| 67 | printk() for debugging purposes may not work, a similar alternative is to use
|
| 68 | trace_printk() , which logs the debug messages to the trace file instead of the
|
| 69 | kernel log.
|
| 70 |
|
| 71 | **Copyright** ©2024 : Collabora
|