Exploring the Powerful Features of GDB

Follow+Star Public Account, don’t miss the wonderful content

Source | Zhihu Wei Yixiao

Embedded development cannot be separated from debugging tools, and there are many debugging tools on the market, but in terms of compatibility and versatility, GDB absolutely holds a leading advantage.

Today, let’s talk about this powerful GDB tool.

Naked Running State: The Original GDB Command Line

Before putting on various clothes, you must at least learn to run naked, find a simple GDB cheat sheet to refer to:

When a crash occurs in the production environment, since online servers generally do not have a development environment or accompanying source code, if you are too lazy to drag the core file back to the development machine for inspection, you can first take a simple look at GDB on the online server.

GDB commands are dense, and the commonly used ones are just a few in the table above. For example, after entering, the first step is to use bt to view the call stack, info local to check local variables, and then use up/down to navigate between different levels of the call stack, checking the values of local variables at various places, and using print to evaluate an expression. Even without code, you can look at the symbols and disassembly, and generally debug quite well.

If you encounter a more complex BUG, you must work with the source code. You need to pull the core file to the development environment and then use GDB to debug against the source code, using list [line number] to view the currently running source code, combined with other methods for debugging.

At this time, if the complexity of debugging continues to rise, you will need to set breakpoints constantly. After each next / step, you will need to list the previous and next source code, or use disassemble [function name/address] to view the instructions. Many people will feel frustrated. At this time, we need to put some pants on the naked GDB.

Putting on Pants: TUI

This is the text interface that comes with GDB, started with the command gdb -tui, for example:

gdb -tui hello

This will open our text interface:

The upper part is the source code window, and the lower part is the GDB terminal. The window management shortcuts mimic Emacs; use c-x o to switch windows. If you also want to view the instruction window, you can enter:<span>layout split</span>

Then when you step through, the source code window above will scroll along, which is much more convenient than constantly listing. To view the previous and next source code, you can continue to use c-x o to switch windows and scroll up and down.

Sometimes after you switch the stack frame with up/down, the code above may not update in time. You can use the update command to let the code window above locate your most recent execution position. Sometimes you may also need to use CTRL-L to redraw the entire interface.

In the TUI mode that comes with GDB, you can not only view code/instructions at any time but also view registers. Well, actually GDB, despite its simplicity, still comes with a pair of pants; it’s just that many people forget to take them out and wear them.

Putting on Underwear: gdbinit

If the information in the above text TUI is not rich enough, you might be interested in .gdbinit. ~/.gdbinit is a GDB configuration script that can set some plugins written in Python, such as peda:

After configuring peda on ~/.gdbinit, you will see the command prompt change from (gdb) to gdb-peda$. Every time you enter a step command, peda will display an incredibly rich set of information, and you can configure to add more, combined with highlighting, to get an enhanced command line.

However, I don’t use this much because it affects the TUI mode’s interface. I don’t like to clutter my GDB with too many things. At the same time, as our debugging needs become more complex, you will need to set breakpoints continuously and frequently step through. These traditional commands in the command line have clearly exhausted us. Can we directly view the source code in the interface and quickly set breakpoints and step through in the code?

Yes, try cgdb.

Putting on a Coat: cgdb

CGDB is similar to GDB TUI, divided into terminal window and code window:

The upper code window is called cgdb mode, and the lower GDB window is called gdb mode. Debugging involves constantly switching between the two modes. The keys mimic Vim; press ESC to switch back to cgdb mode and i to switch to gdb mode.

This looks similar to TUI GDB, right? Besides syntax highlighting, where is it more efficient than GDB TUI? The answer is: most operations can be performed in cgdb mode (the source code window) using shortcuts.

You can move the cursor with the arrow keys or <span>hjkl</span>, flip pages with <span>page-down/up</span> or <span>c-f / c-b</span>, and pressing the o key will list the source code of the current executable file, allowing you to switch to view other related code files. Press <span>/</span> or <span>?</span> to search the document.

These shortcuts correspond to Vim, allowing you to conveniently browse source code while you can use the space bar to toggle breakpoints in the code window, along with other shortcuts:

• F5 – Send a run command to GDB.
• F6 – Send a continue command to GDB.
• F7 – Send a finish command to GDB.
• F8 – Send a next command to GDB.
• F10 – Send a step command to GDB.

For more shortcuts, see 【here】. Now stepping through and setting breakpoints is much easier. You can basically stay in the source code window without coming out, and most of the time you no longer need to input each <span>next/step</span> in the GDB command line.

Edit ~/.cgdb/cgdbrc to make it easier to use:

set ignorecase
set ts=4
set wso=vertical
set eld=shortarrow
set hls
map <F9> :until<cr>

This roughly sets the search to be case insensitive, the tab size, the split screen mode (default to left-right split), highlights the search, and adds a F9 shortcut key for breaking out of loops (this shortcut is not available by default):

Now that everyone uses wide-screen monitors, changing the default to left-right split (requires cgdb 7.0) is much more comfortable.

CGDB has more features, such as viewing assembly when there are no source files, or cross-viewing source code and assembly, setting marks, etc. For specifics, see its official documentation.

This small tool can free you from a lot of GDB command lines, and the configuration file can also allow you to bind various commands to shortcuts according to your preferences.

Dressed Neatly: Emacs GDB

Although CGDB allows most operations to be performed with shortcuts, there are still many times when you need to switch back to the right GDB mode to enter commands. For example, when you need to use info local to check local variables or print to check the value of a global variable after each step, frequent switching between left and right can be exhausting.

When debugging relatively complex issues, the above tools may not hold up. For those who usually write code in Vim, I also do not refuse to use Emacs’s GDB mode to debug some complex issues. Undoubtedly, Emacs is currently the strongest GDB frontend in the terminal.

If you have never used Emacs, it’s okay; just install Emacs and remember the following commands to debug:

• Switch files: c-x c-f (press ctrl_x then ctrl_f), you can use tab for completion when entering the file name
• Move the cursor: arrow keys, or c-f, c-b, c-p, c-n; flip pages with pgup/down or c-v / m-v
• Switch buffers: c-x b to switch the current window’s buffer, c-x c-b to open a new window to switch buffers.
• Window operations: c-x o window switching, c-x 2 / c-x 3 for up/down/left/right split screens, c-x 0 / c-x 1 to close / make exclusive
• Input command: m-x (press ALT_x) to input commands, you can use tab for completion, c-g to exit command input.

Of course, don’t forget that the exit command is c-x c-c. That’s enough; first, we start Emacs:

Press m-x (alt+x), it prompts you to enter a command (if the terminal software’s alt key does not work, you can set it, or press ESC first for one second, then press x, which is equivalent in xterm terminal), type gdb and hit enter:

Then it will ask you how to run GDB, enter the shell command to start GDB and hit enter to start GDB mode:

At this point, you may ask, is there any difference between this and directly using the command line GDB? Don’t rush, continue to input the command m-x:

gdb-many-windows

Immediately satisfy you:

These gud- prefixed commands are the universal debugging commands in Emacs GDB mode, which correspond one-to-one with GDB commands. You can input these commands using m-x, and you can also operate using shortcuts.

If you want to replace one of the windows with a disassembly or register monitoring, you can use m-x to input:

gdb-display-disassembly-buffer

Then one of the windows will be switched to the disassembly window:

The upper left GDB terminal has been switched to the disassembly window. After viewing, remember to switch back to the GDB console with c-x b. If you want to prevent a window from being switched away, you can search for Emacs’s dedicated window. Moreover, we can use window management shortcuts to split the layout according to our preferences:

For example, I split it again, moving the GDB terminal to the right, the output window below, and displaying the disassembly in the place that originally showed the GDB terminal. Basically, all the debugging methods you see in IDEs can be operated in Emacs, and Emacs can also debug Mingw programs under Windows.

Perhaps you might complain that operating in Emacs is too cumbersome; don’t worry, just a little adjustment will do.

Adjusting Emacs GDB Mode

Open ~/.emacs (under Windows it’s ~/_emacs) and enter the following content:

(global-set-key [M-left] 'windmove-left)
(global-set-key [M-right] 'windmove-right)
(global-set-key [M-up] 'windmove-up)
(global-set-key [M-down] 'windmove-down)

(global-set-key [f5] 'gud-run)
(global-set-key [S-f5] 'gud-cont)
(global-set-key [f6] 'gud-jump)
(global-set-key [S-f6] 'gud-print)
(global-set-key [f7] 'gud-step)
(global-set-key [f8] 'gud-next)
(global-set-key [S-f7] 'gud-stepi)
(global-set-key [S-f8] 'gud-nexti)
(global-set-key [f9] 'gud-break)
(global-set-key [S-f9] 'gud-remove)
(global-set-key [f10] 'gud-until)
(global-set-key [S-f10] 'gud-finish)

(global-set-key [f4] 'gud-up)
(global-set-key [S-f4] 'gud-down)

(setq gdb-many-windows t)

To explain, the top settings allow ALT + arrow keys to jump between windows. If your terminal’s alt + arrow keys do not work, you can change it to C-left, C-right, etc., to move the window using ctrl + arrow keys. The subsequent settings are shortcuts for commonly used commands.

Finally, set it to open gdb-many-windows by default, and the following section allows mouse operations:

(require 'xt-mouse)
(xterm-mouse-mode)
(require 'mouse)
(xterm-mouse-mode t)
(defun track-mouse (e))

(setq mouse-wheel-follow-mouse 't)

(defvar alternating-scroll-down-next t)
(defvar alternating-scroll-up-next t)

(defun alternating-scroll-down-line ()
  (interactive "@")
    (when alternating-scroll-down-next
      (scroll-down-line))
    (setq alternating-scroll-down-next (not alternating-scroll-down-next)))

(defun alternating-scroll-up-line ()
  (interactive "@")
    (when alternating-scroll-up-next
      (scroll-up-line))
    (setq alternating-scroll-up-next (not alternating-scroll-up-next)))

(global-set-key (kbd "<mouse-4>") 'alternating-scroll-down-line)
(global-set-key (kbd "<mouse-5>") 'alternating-scroll-up-line)

Now in xterm, you can click to switch windows, click buttons, and use the scroll wheel to view source code:

Now it’s much more flexible; you can switch windows with ALT + arrow or mouse clicks, and operate using the commands below:

• F5 – Run, Shift + F5 – Continue
• F7/F8 for code-level stepping, and Shift-F7/F8 for instruction-level stepping
• F9 – Set breakpoint, Shift-F9 to delete breakpoint
• F10 – Jump out of loop, Shift-F10 to jump out of function
• F4 – Move to the previous call stack frame, Shift-F4 to move to the next

The upper right local variable window has two buttons that can be clicked with the mouse to switch between displaying local variables or registers. The lower right also has two buttons to switch between displaying breakpoints or threads. The buttons in the green section at the top can also be clicked directly with the mouse.

Finally, this is much better than our initial version. If you like to tinker, you can also customize the initial layout of gdb-many-windows to be more complex:

Completely satisfying your various complex debugging needs; I won’t elaborate here. If you’re interested, see 【this article】.

Finally, opening Emacs every time to input m-x and then typing the file name is cumbersome? Let’s adjust .bashrc:

gdbtool () { emacs --eval "(gdb \"gdb --annotate=3 -i=mi $*\")";}

Now, in the terminal, we only need to enter:

$ gdbtool hello

To automatically open Emacs and switch to GDB mode, expanding our multi-window layout and starting debugging. Isn’t that pleasant?

I usually first use gdb-tui to take a look when I don’t have an environment. If there is an environment or the problem is complex, I will open Emacs for debugging. Later

After being introduced to cgdb, gdb-tui has been retired. I first use cgdb to get a general idea when there is no environment, and for complex problems, I open Emacs. After some adjustments, it is very handy.

Making GDB More Attractive

Actually, by the time we reach Emacs, we are almost done. But if you really can’t remember these limited shortcuts or GDB commands, you can try gdbgui:

A browser-based GDB frontend developed in Python, simply install it with pip, and when using it:

gdbgui --host 0.0.0.0 hello

This will listen on local port 5000, and we can open the server’s address in a browser to debug completely using the mouse.

The middle shows the program code, the bottom shows the GDB terminal, and the top can switch source code, controlling run/continue/step, etc. On the right, you can view in real-time: local variables, call stack frames, memory addresses, breakpoints, threads, etc.

For example, the above shows the call stack and thread view, as well as the custom structure query below:

It can also visually query data structures:

Mouse-clicking to the left of the code sets/deletes breakpoints, and clicking the buttons above switches to display assembly code. Basically, it presents the main functions of GDB in a visual way, showcasing a modern web interface in front of you, without needing to remember any shortcuts, just point and click.

Additionally, this gdbgui also supports GDB debugging under Windows. Currently, gdbgui is still actively being developed, and as the most attractive GDB frontend, it will undoubtedly become more powerful.

Conclusion

Alright, we have experienced the journey from the original GDB command line naked running state to the most complete debugging environment in the terminal, Emacs GDB mode, and then to the attractive gdbgui. The benefit of GDB is that it can incorporate various plugins internally and provide various interfaces externally, allowing you to manage debugging tasks well while leaving the frontend interface completely to other programs, whether local or remote. That’s why there are various rich GDB Front Ends and various remote GDB tools.

It does not limit you to say that you can only debug this way or that you only have a single UI to operate. Therefore, the combination methods of GDB are countless; you don’t need to feel that GDB only has the original command input method. Right? With so many methods above, just choose a couple, and it won’t take half an hour to significantly speed up your debugging work in the terminal.

Source link: https://zhuanlan.zhihu.com/p/32843449

Disclaimer: The materials in this article are sourced from the internet, and the copyright belongs to the original author. If there are any copyright issues, please contact me for deletion.