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