C/C++ Development Environment for Emacs

• Know how to use package.el and MELPA. If you don't know how to use, read the guide How to use Emacs package manager.

• Install GNU Global from your distribution's package manager (Linux / Mac) or from the Win32 port (Windows). If none is available, download the sources here and manually build the package. Do be aware that it is remotely possible that your package manager might install an outdated version that might impair some functionality of helm-gtags.

• Install ggtags. After installing ggtags from MELPA, add this code snippet to setup ggtags and key bindings:

(require 'ggtags)
(add-hook 'c-mode-common-hook
          (lambda ()
            (when (derived-mode-p 'c-mode 'c++-mode 'java-mode 'asm-mode)
              (ggtags-mode 1))))

(define-key ggtags-mode-map (kbd "C-c g s") 'ggtags-find-other-symbol)
(define-key ggtags-mode-map (kbd "C-c g h") 'ggtags-view-tag-history)
(define-key ggtags-mode-map (kbd "C-c g r") 'ggtags-find-reference)
(define-key ggtags-mode-map (kbd "C-c g f") 'ggtags-find-file)
(define-key ggtags-mode-map (kbd "C-c g c") 'ggtags-create-tags)
(define-key ggtags-mode-map (kbd "C-c g u") 'ggtags-update-tags)

(define-key ggtags-mode-map (kbd "M-,") 'pop-tag-mark)

• Or, helm + helm-gtags. Helm is awesome and if you are going to use Helm, please read the Helm guide. Remember to setup Helm before using helm-gtags. You can use this sample configuration. When includes the above file in your ~/.emacs.d, remember to add (require 'setup-helm) to your init.el.

(setq
 helm-gtags-ignore-case t
 helm-gtags-auto-update t
 helm-gtags-use-input-at-cursor t
 helm-gtags-pulse-at-cursor t
 helm-gtags-prefix-key "\C-cg"
 helm-gtags-suggested-key-mapping t
 )

(require 'helm-gtags)
;; Enable helm-gtags-mode
(add-hook 'dired-mode-hook 'helm-gtags-mode)
(add-hook 'eshell-mode-hook 'helm-gtags-mode)
(add-hook 'c-mode-hook 'helm-gtags-mode)
(add-hook 'c++-mode-hook 'helm-gtags-mode)
(add-hook 'asm-mode-hook 'helm-gtags-mode)

(define-key helm-gtags-mode-map (kbd "C-c g a") 'helm-gtags-tags-in-this-function)
(define-key helm-gtags-mode-map (kbd "C-j") 'helm-gtags-select)
(define-key helm-gtags-mode-map (kbd "M-.") 'helm-gtags-dwim)
(define-key helm-gtags-mode-map (kbd "M-,") 'helm-gtags-pop-stack)
(define-key helm-gtags-mode-map (kbd "C-c <") 'helm-gtags-previous-history)
(define-key helm-gtags-mode-map (kbd "C-c >") 'helm-gtags-next-history)

Before using the ggtags or helm-gtags, remember to create a GTAGS database by running gtags at your project root in terminal:

$ cd /path/to/project/root
$ gtags

After this, a few files are created:

$ ls G*
GPATH   GRTAGS  GTAGS

• GTAGS: definition database
• GRTAGS: reference database
• GPATH: path name database

If you use ggtags, you have a command for creating GTAGS database, that is ggtags-create-tags; this is recommended way when using ggtags, to let it know where the project root is.

• C-M-f runs forward-sexp, move forward over a balanced expression that can be a pair or a symbol. Demo:

  

• C-M-b runs backward-sexp, move backward over a balanced expression that can be a pair or a symbol. Demo:

  

• C-M-k runs kill-sexp, kill balanced expression forward that can be a pair or a symbol. Demo:

  

• C-M-<SPC> or C-M-@ runs mark-sexp, put mark after following expression that can be a pair or a symbol. Demo:

  

• C-M-a runs beginning-of-defun, which moves point to beginning of a function. Demo:

  

• C-M-e runs end-of-defun, which moves point to end of a function. Demo:

  

• C-M-h runs mark-defun, which put a region around whole current or following function. Demo:

  

A tag is a name of an entity in source code. An entity can be a variable, a method definition, an include-operator… A tag contains information such as name of the tag (the name of the variable, class, method), location of this tag in source code and which file it belongs to. As an example, GNU Global generates three tag databases:

• GTAGS: definition database
• GRTAGS: reference database
• GPATH: path name database

A definition of a tag is where a tag is implemented. For example, a function definition is the body where it is actually implemented, or a variable definition is where the type and its property (i.e static) is specified.

A reference of a tag is where a tag is used in a source tree, but not where it is defined.

The Imenu facility offers a way to find the major definitions, such as function definitions, variable definitions in a file by name. ggtags can integrate Imenu:

(setq-local imenu-create-index-function #'ggtags-build-imenu-index)

If you use Helm, use moo-jump-local from function-args package. You can use it as an outline tree like in other IDEs. Here is a demo:

• Using gtags: by default, M-. runs ggtags-find-tag-dwim when ggtags-mode is enabled. The command ggtags-find-tag-dwim jump to tag base on context:
  • If the tag at point is a definition, ggtags jumps to a reference. If there is more than one reference, it displays a list of references.
  • If the tag at point is a reference, ggtags jumps to tag definition.
  • If the tag at point is an include header, it jumps to that header.

You can jump back to original location where you invoked ggtags-find-tag-dwim by M-,, which runs pop-tag-mark (if you follow my key bindings).

You can also find arbitrary tag definition when invoking M-. on blank space. A prompt asks you for tag pattern, which is a regexp.

If ggtags gives you a list of candidates, you can use M-n to move to next candidate and M-p to move back previous candidate. Use M-g s to invoke Isearch on candidate buffer list.

• Using helm-gtags: If key bindings are properly setup as above, M-. runs helm-gtags-dwim, which behaves the same as ggtags-find-tag-dwim. Similarly, you jump back to original location by using M-,, which runs tags-loop-continue (Emacs default).

You can also find arbitrary tag definition when invoking M-. on blank space. A prompt asks you for tag pattern, which is a regexp.

helm-gtags provides a really nice feature that uses Helm to display all available tags in a project and incrementally filtering, and is really fast using helm-gtags-select, which is bound to C-j in my setup above. This is useful when you want to explore tags in unfamiliar project. Demo:

• Using ggtags: Either run ggtags-find-tag-dwim or ggtags-find-reference, which only finds references.
• Using helm-gtags: Either run helm-gtags-dwim or helm-gtags-find-rtags, bound to C-c g r, which only finds references. Note that for helm-gtags-find-rtags:
  • if point is inside a function, the prompt will be default to the function name.
  • If point is on a function, it lists references of that functions immediately.
  • If point is on a variable, helm-gtags-find-rtags won't have any effect. You should use helm-gtags-find-symbol, which is bound to C-c g s.

Find functions that calls function is actually a special case of finding references. That is, you gather references for a function.

If you want to list all the functions that the current function - the function that point is inside - calls, you can do that with helm-gtags-tags-in-this-function, which is bound to C-c g a in my setup.

• Using ggtags: Run ggtags-find-file to find a file from all the files indexed. If point is on an included header file, ggtags-find-tag-dwim automatically jumps to the file.
• Using helm-gtags: Run helm-gtags-find-files to find files matching regexp. If point is on an included header file, helm-gtags-dwim automatically jumps to the file.

Alternatively, you have a more generic solution, that is using Projectile. Projectile is a generic project management tool that you learn later. With Projectile, jumping around version controlled project like Linux kernel is a breeze, since you can jump to any file regardless of where you are standing in the project.

• Using ggtags: As you know that you can jump back with pop-tag-mark (bound to M-,), you can also view a list of visited tags using ggtags-view-tag-history, which is bound to C-c g h. It displays visited tags from newest to oldest, that is from top to bottom.
• Using helm-gtags: Similarly, helm-gtags also has the command helm-gtags-show-stack that shows visited tags from newest to oldest, from top to bottom.

However, you may feel that a frame is difficult to use. To solve this issue, you need sr-speedbar, which can be installed via MELPA.

• To open sr-speedbar, execute the command sr-speedbar-open or sr-speedbar-toggle.
• To close sr-speedbar, execute the command sr-speedbar-close or sr-speedbar-toggle again.

Best is to use sr-speedbar-toggle only, for simplicity.

sr-speedbar gives the following improvements:

• Automatically switches directory tree - when you switch buffer - to the default-directory of current buffer.
• Use an Emacs window instead of frame, make it easier to use.
• C-x 1 deletes every window except Speedbar, so you won't have to open again.
• You can prevent C-x o to jump to sr-speedbar window by setting sr-speedbar-skip-other-window-p to `t`. You can still move to sr-speedbar window using either the mouse or windmove.

Demo: In the demo, you can see that the function set-cpu-active is being highlighted. That's what happens when you press RET on a tag: Speedbar moves to the location of that tag and highlight it. Looking at the Speedbar, under set-cpu-active node, it contains these children:

• The first child is always the return type, void.
• The subsequent children are function parameters. Inside each function parameter node is its type.

CEDET is a (C)ollection of (E)macs (D)evelopment (E)nvironment (T)ools written with the end goal of creating an advanced development environment in Emacs. CEDET includes common features such as intelligent completion, source code navigation, project management, code generation with templates . CEDET also provides a framework for working with programming languages; support for new programming languages can be added and use CEDET to provide IDE-like features.

CEDET can give you code completion, but this process takes time and can block your Emacs while it is doing so. If you have large project, you may not want to use CEDET for code completion. But, you can use CEDET perfectly for utilities that work at file scope i.e. refactoring local variables in a function in a file.

CEDET is simple to setup and portable (right winthin Emacs and written entirely with Emacs Lisp). Without CEDET, you have to use external tools and third party Emacs packages. The downside of external tools is that they are not specifically designed for Emacs. They have similar use cases, but not always satisfying. For example, source code indexing tools such as GNU Global and Exuberant Ctags are really good at working static source code, but they do not keep track changes in real time; CEDET does:

As you can see, CEDET recognizes when printk.h is included and provides appropriate completion candidates. In contrast, non-context sentisve completion is like this:

In this case, the completion system gets all candidates straight from GNU Global generated database without considering current context.

The disadvantage is that CEDET is written in Emacs Lisp, and it is bound to the performance limitations of Emacs. Even though, CEDET is still really fast for moderate-size source files. CEDET also makes use of external tools like GNU Global or Cscope or Exuberant Ctags for finding symbol references/definition in a project to reduce its workload.

CEDET was merged into Emacs since 23.2. You do not need to install CEDET manually. However, you can also use the development repository that contains latest bug fixes and more features. Nevertheless, the built-in Emacs is still adequate for daily usage and convenient for trying out before actually cloning and use the development version. Skip this section if you only want to try Emacs. Come back later if you really like it.

If you really want to use the development version with latest feature, checkout this branch:

git clone http://git.code.sf.net/p/cedet/git cedet

Be sure to place the checked out cedet directory in your ~/.emacs.d. Then compile it:

cd cedet
make # wait for it to complete
cd contrib
make

Finally, assume that you placed your newly cloned CEDET in ~/.emacs.d, load it into your Emacs:

(load-file (concat user-emacs-directory "/cedet/cedet-devel-load.el"))
(load-file (concat user-emacs-directory "cedet/contrib/cedet-contrib-load.el"))

Semantic is a package that provides language-aware editing commands based on source code parsers. Parsing is a process of analyzing source code based on programming language syntax. Emacs understands your source code through this process to provides features such as contextual code completion, code navigation. Here is an example how Semantic helps you provides completion for Boost:

This guide only covers a portion of CEDET. Since Semantic parses source code and creates a database for code completion, it would be useful to reuse the database for other features such as code navigation, jump to definition and gather references. These are cool features. For example, CEDET provide nice syntax highlighting for gathering references:

The above feature is called Semantic Symref. It queries tag references from SemanticDB and display the result in another buffer. Please refer to GNU Manual - Symbol References for more info. If your project is only the size of Emacs or similar, then Semantic Symref is a viable choice. Remember that when entering new files, Semantic takes time to parse and if you gather references for the first time, you will have to wait for a while for Semantic doing its job. After the first time, subsequent uses of Semantic Symref happens instantly.

But, for navigating around the source tree, we already have ggtags and helm-gtags, which uses GNU Global for much faster indexing for large project like Linux kernel. The only thing that other tools cannot do, is context-sensitive completion. That's why we only use CEDET for code completion in this guide. Nevertheless, Semantic Symref is still a viable choice for small to medium sized projects. Choose the one you prefer.

Other solutions that use clang is quite good but not there yet. For example, auto-complete-clang is fine for getting system header candidates (since clang has system paths by default), but it has no concept of project and is not aware of project include path. You can add more arbitrary include paths to auto-complete-clang, but it won't be pretty: once you add an include path for a project, it is visible to all other projects since the include path is treat as system include path. That means, whenever you try to complete something, you get irrelevant candidates from other projects as well. Quite annoying. company-clang also has the same problem. Another solution is rtags, but it is really complicated to setup, especially if you use make; I never succeed with it. clang based packages still have a long way to go. CEDET also supports clang for retrieving completion candidates. It also has the limitations of other packages.

CEDET is best used with new project, because Semantic parse code as you write. As a result, you won't have to wait for parsing unknown source files to get completion candidates.

Senator is a part of CEDET. Senator stands for SEmantic NAvigaTOR. Senator provides some useful commands for operating on semantic tags in SemanticDB. As you can see, another utility makes use of SemanticDB, aside from smart completion. It is like the heart of CEDET: once Semantic fails to parse, tools centered around it fail as well. If such situation happens, you always have a reserved and simpler solution: use GNU Global with ggtags or helm-gtags frontends. The following commands are provided by Senator:

EDE, short for Emacs Development Environment, is a generic interface for managing projects. In EDE, a project hierarchy matches a directory hierarchy. The project's topmost directory is called the project root, and its subdirectories are sub-projects.

EDE can do many things but we will just use it for code completion at project level. To demonstrate the use of EDE, we will create a little project of our own.

To setup EDE:

(require 'ede)
(global-ede-mode)

Now, let's try completion in main.c using moo-complete or company-semantic. Nothing also happens. It is because Semantic only looks for header files in current directory by default. If you put it elsewhere, you have to tell Semantic where it is. This is not limited to only Semantic; you have to specify project include path in Eclipse as well.

• Create a new file called cedet-projects.el in ~/.emacs.d/.
• In this file, add a new ede-cpp-root-project in this form:

(ede-cpp-root-project "project_root"
                      :file "/dir/to/project_root/Makefile")

The first argument to ede-cpp-root-project is project name. :file argument specifies path to project root. You must create a file in the project root, since EDE uses that file as an "anchor" to project root; in our case, Makefile is the anchor file. Not sure why EDE just straightly uses root directory.

• Add include directories specific to the project and in your system:

(ede-cpp-root-project "project_root"
                      :file "/dir/to/project_root/Makefile"
                      :include-path '("/include1"
                                      "/include2") ;; add more include
                      ;; paths here
                      :system-include-path '("~/linux"))

:include-path specifies directories local to your projects that EDE should search first when looking for a header file. :incluide-path is relative to project root specified in :file.

:system-include-path specifies system include paths that do not belong to current project. Note that despite it is called system-include-path, it does not have to be in place like /usr/include. You can specify any include directories outside of your current project as "system headers".

After done setting up your project, save the file and execute that ede-cpp-root-project expression with C-x C-e. Now, Semantic is aware of your project include paths. However, you have to do one last thing: either close the file main.c and reopen it or M-x semantic-force-refresh to tell Semantic to analyze main.c again. Otherwise, Semantic will still keep the previous parsing result of this file and completion candidates won't be available. As a result, it is important to load EDE projects defined by ede-cpp-root-project before opening any project file.

After that, try auto-completion and you will see everything is working fine again:

Summary:

• EDE, short for Emacs Development Environment, is a generic interface for managing projects.
• EDE enables Semantic to find sources and perform project level completions.
• To add a C/C++ project, simply create a project definition with this template in a file, such as ede-projects.el:

(ede-cpp-root-project "project_root"
                      :file "/dir/to/project_root/Makefile"
                      :include-path '("/include1"
                                      "/include2") ;; add more include
                      ;; paths here
                      :system-include-path '("~/linux"))

• Load ede-projects.el when Emacs start.
• If you have opening files, either close or refresh it with M-x semantic-force-refresh to make Semantic aware of new changes.

Later, you will also learn another project management tool called Projectile. You may ask, why another project management tool? The differences are:

• EDE is older, Projectile appears recently.
• EDE manages project files to integrate with specific build system and generate corresponding build file (such as Makefile; these features are not covered in this guide). Projectile provides generic file management operations such as quickly jump to file/directory in project, list buffers that belong to current project…
• EDE is part of CEDET suite; it is geared toward Semantic. For example, we used EDE to tell Semantic where to retrieve correct include paths for current project to perform smart completion in previous section. Projectile provides a generic interface for managing your project under a VCS or some supported build system.
• Projectile is easier to learn than EDE.

Both have some overlapping in features, such as Projectile provides basic tag navigation in project, but in general they support each other. For our basic usage, we use EDE for smart completion as in previous section and Projectile to navigate our project effortlessly.

Semantic provides a jump command based on the parsed tags produced by the Semantic C/C++ parser. To jump to any code in system include path, you must first tell Semantic where it is:

(semantic-add-system-include "/usr/local/include")
(semantic-add-system-include "~/linux/include")

Then, if point is on an include header like #include <iostream> or a tag inside iostream, executing the command semantic-ia-fast-jump will jump to into header file or jump to the tag at point earlier that is inside iostream. If the tag is actually within iostream but you do not include iostream, Semantic won't be able to jump because it sees no appropriate header that contains the tag.

The function semantic-add-system-include will add your include paths to semantic-c-dependency-system-include-path variable. By default, it only contains /usr/include. You can add more such as /usr/local/include or your own project, such as ~/linux/include.

The disadvantage of using Semantic is that for it may take brief while to parse, but for once; the next time you can jump to parsed source instantly.

GNU Global has an environment variable named GTAGSLIBPATH. This variable holds GTAGS database of external libraries that your project depends on but not inside your project. For example, your project may rely on system headers such as stdio.h, stdlib.h… but these headers are internal to your project. However, remember that you can only jump to tag definitions of external dependencies, and nothing else (such as files or references). But, again, once you are inside the external library, you can start jumping around sicne it becomes your current project.

To make GNU Global sees your system headers, follow these steps:

• Export this environment variable in your shell init file, such as .bashrc or .zshrc:

export GTAGSLIBPATH=$HOME/.gtags/

• Execute these commands in your terminal:

# Create a directory for holding database, since
# you cannot create a database in your system paths
mkdir ~/.gtags

# Create symbolic links to your external libraries
ln -s /usr/include usr-include
ln -s /usr/local/include/ usr-local-include

# Generate GNU Global database
gtags -c

The -c option tells GNU Global to generate tag database in compact format. It is necessary because if your project contains C++ headers like Boost, without -c your GTAGS database can be more than 1 GB. Same goes for ctags. The GNU Global devs explained that it is because the GTAGS database includes the image of tagged line, and the Boost headers have a lot of very long lines.

After all the above steps, restart with a shell loaded with that variable. To verify Emacs gets the variable, M-x getenv and enter GTAGSLIBPATH and see if your predefined value is available. Executing ggtags-find-tag-dwim or helm-gtags-dwim jumps to the definition of a system tag like a normal tag.

The disadvantage of using GNU Global is that currently it cannot include files without extension. In the C++ system include directory like /usr/include/c++/4.8/, it contains files without extension such as iostream, string, set, map…. so you can write #include directives without having to append .h at the end. GNU Global devs are considering to add support for this use case.

This mode, when enabled, displays function interface in the minibuffer:

It works well for C but not C++, since C++ can overload function and semantic-idle-summary-mode can only display one interface at a time. Since this mode is part of Semantic, it also relies on SemanticDB that is created from parsing source files.

Setup:

(global-semantic-idle-summary-mode 1)

When enable, this mode shows the function point is currently in at the first line of the current buffer. This is useful when you have a very long function that spreads more than a screen, and you don't have to scroll up to read the function name and then scroll down to original position.

Please click here for demos.

Setup:

(add-to-list 'semantic-default-submodes 'global-semantic-stickyfunc-mode)

One of the problem with current semantic-stickyfunc-mode is that it does not display all parameters that are scattered on multiple lines. This package handles that problem: semantic-stickyfunc-enhance. Extra: stock semantic-stickyfunc-mode does not include assigned values to function parameters of Python. This package also fixed that problem. You can click the link to see demos.

You can install the package via MELPA and load it:

(require 'stickyfunc-enhance)

You can also use ggtags for displaying function interface at point in minibuffer:

(setq-local eldoc-documentation-function #'ggtags-eldoc-function)

However, it won't have syntax highlighting.

To read the documentation for symbol at point or a man entry of your choice, invoke M-x man.

If you use Helm, you should be able to use the command helm-man-woman, which is bound to C-c h m if you follow my Helm guide. The full guide for the command is here.

Emacs has a minor mode called hs-minor-mode that allows users to fold and hide blocks of text. Blocks are defined by regular expressions which match the start and end of a text region. For example, anything in between { and } is a block. The regular expressions are defined in hs-special-modes-alist.

Setup for C/C++:

(add-hook 'c-mode-common-hook   'hs-minor-mode)

Default key bindings:

Demo:

• Command: hs-toggle-hiding

Narrowing means making only a text portion in current buffer visible. Narrowing is useful when you want to perform text editing on a small part of the buffer without affecting the others. For example, you want to delete all printf statements in current functions, using flush-lines command. But if you do so, you will also delete printf outside the current function, which is undesirable. By narrowing, you can safely remove all those printf and be certain that nothing else is changed accidentally.

Default key bindings:

YASnippet is a template system for Emacs. It allows you to type an abbreviation and automatically expand it into function templates. Bundled language templates include: C, C++, C#, Perl, Python, Ruby, SQL, LaTeX, HTML, CSS and more. The snippet syntax is inspired from TextMate's syntax, you can even import most TextMate templates to YASnippet.

Setup:

;; Package: yasnippet
(require 'yasnippet)
(yas-global-mode 1)

Usage:

In major modes where yasnippet has snippets available, typing a certain keyword and TAB insert a predefined snippet. For example, in a C buffer, if you type for and TAB, it expands to:

for (i = 0; i < N; i++) {
    ...point will be here....
}

You can view supported snippets here.

smartparens is a minor mode that provides many features for manipulating pairs. Pair can be simple as parentheses or brackets, or can be programming tokens such as if … fi or if … end in many languages. The most basic and essential feature is automatic closing of a pair when user inserts an opening one.

  ;; Package: smartparens
(require 'smartparens-config)
(show-smartparens-global-mode +1)
(smartparens-global-mode 1)

;; when you press RET, the curly braces automatically
;; add another newline
(sp-with-modes '(c-mode c++-mode)
  (sp-local-pair "{" nil :post-handlers '(("||\n[i]" "RET")))
  (sp-local-pair "/*" "*/" :post-handlers '((" | " "SPC")
                                            ("* ||\n[i]" "RET"))))

For complete documentation, please refer to Smartparens manual.

Emacs has built-in frontend support for GDB that provides IDE-like interface. It has a layout like this:

Stock Emacs doesn't enable this layout by default. You have to tell Emacs to always use gdb-many-windows:

(setq
 ;; use gdb-many-windows by default
 gdb-many-windows t

 ;; Non-nil means display source file containing the main routine at startup
 gdb-show-main t
 )

Now, find a binary built for debugging, and start GDB by M-x gdb. Emacs prompts asking you how to run gdb. By default, the prompt looks like this:

To use gdb-many-windows, you must always supply the -i=mi argument to gdb, otherwise gdb-many-windows won't work. By default, as you've seen the layout of gdb-many-windows above, you have the following buffers visible on your screen (ignore the first row):

Each cell coressponds to the following commands:

• gdb-display-gdb-buffer (Cell 1): This is where you enter gdb commands, the same as in terminal. When you kill this buffer, other GDb buffers are also killed and debugging session is terminated.
• gdb-display-locals-buffer (Cell 2): display local variables and its values in current stack frame. Please refer to GNU Manual - Other GDB Buffers for usage of the buffer.
• gdb-display-registers-buffer (Cell 2): registers values are displayed here. Please refer to GNU Manual - Other GDB Buffers for usage of the buffer.
• Your source buffer (Cell 3): Your source code for stepping through out the debugging session. Please refer to GNU Manual - Source Buffers for usage of the buffer.
• gdb-display-io-buffer (Cell 4): This is where your program displays output and accepts input. In stock GDB (Command Line Interface), you enter input whenever a program asks for one under GDB prompt. Using gdb-many-windows, you must enter program input here.
• gdb-display-stack-buffer (Cell 5): Display function call stack. Please refer to GNU Manual - Stack buffer for usage.
• gdb-display-breakpoints-buffer (Cell 6): Display a list of breakpoints. Please refere to GNU Manual - Breakpoints Buffer for usage of the buffer.
• gdb-display-threads-buffer (Cell 6): Display running threads in your programs. Please refer to GNU Manual - Threads Buffer and Multithreaded Debugging for usage of the buffer.

There are two useful commands that are not visible in gdb-many-windows:

• gdb-display-disassembly-buffer: displays the current frame as assembly code.
• gdb-display-memory-buffer: displays a portion of program memory.

There are another variants of the above buffers, with gdb-frame prefix instead of gdb-display. When you run commands with gdb-frame prefix, the buffers are opened in a new frame instead of occupying an existing window. This is useful when you have 2 monitors, one is for the standard gdb-many-windows layout and another one is for displaying disassembly buffer and memory buffer in a separate frame.

The Grand Unified Debugger, or GUD for short, is an Emacs major mode for debugging. It works on top of command line debuggers. GUD handles interaction with gdb, dbx, xdb, sdb, perldb, jdb, and pdb, by default. Emacs provides unified key bindings for those debuggers. We only concern about GDB in this guide.

GUD works by sending text commands to a debugger subprocess, and record its output. As you debug the program, Emacs displays relevant source files with an arrow in the left fringe indicating the current execution line. GUD is simple and stable. When starting GUD, you only have a GDB command buffer and your source file. If you like simplicity, you can use GUD. However, you can still use other gdb-display- or gdb-frame- variants listed in previous section when needed.

As you can see, the default Emacs interface also includes a menu for regular debugging operations, such as Stop, Run, Continue, Next Line, Up/Down Stack…

Refer to a list of commands supported by GUD at GNU Emacs Manual - Commands of GUD. Note that these key bindings not only work with GDB, but any debuggers supported by GUD, since it's a Grand Unified Debugger.

There's an Emacs packages that offers support for more debuggers: emacs-dbgr. Here is the list of supported debuggers. If you have to work with many languages, use GUD.