cgdb/cgdb

Console front-end to the GNU debugger

CGDB

CGDB is a very lightweight console frontend to the GNU debugger. It provides a split screen interface showing the GDB session below and the program's source code above. The interface is modelled after vim's, so vim users should feel right at home using it.

Screenshot, downloads, and documentation are available from the home page: https://cgdb.github.io

Official source releases are available here: https://cgdb.me/files/

Build Instructions

Dependencies

You must have the following packages installed.

• sh
• autoconf
• automake
• aclocal
• autoheader
• libtool
• flex
• bison
• gcc/g++ (c11/c++11 support)

Preparing the configure

Run ./autogen.sh in the current working directory to generate the configure script.

Running configure, make and make install

You can run ./configure from within the source tree, however I usually run configure from outside the source tree like so,

mkdir ../build
cd ../build
../cgdb/configure --prefix=$PWD/../prefix
make -srj4
make install

CGDB is a C11/C++11 project, just like GDB. Since the standard is relatively new, your gcc/g++ may support it out of the box, or may require the -std=c11 and -std=c++11 flags. You can see how to set these flag in the below configure invocation.

I typically enable more error checking with the build tools like so,

YFLAGS="-Wno-deprecated" CFLAGS="-std=c11 -g -O0 -Wall -Wextra -Wshadow -pedantic -Wno-unused-parameter" CXXFLAGS="-std=c++11 -g -O0 -Wall -Wextra -Wshadow -Werror -pedantic -Wmissing-include-dirs -Wno-unused-parameter -Wno-sign-compare -Wno-unused-but-set-variable -Wno-unused-function -Wno-variadic-macros" ../cgdb/configure --prefix=$PWD/../prefix

If you like to have a silent build, and the libtool link lines are bothering you, you can set this environment variable to suppress libtools printing of the link line,

LIBTOOLFLAGS=--silent

cgdb's Issues

Implement commands that allows us to map the built in cgbd mode hotkeys.

How can we directly swap a hotkey's function with another key that doesnt have a callable ex mode command? (this is assuming the manual shows all available commands).

For example swapping n, N's search function with j's movement function?

As somebody who uses the colemak keymap, many of the already assigned hotkeys are my movement keys and I have no option but to just override the functions. Which sucks.

So you can get a better idea of what im talking about here is my hotkey config and the colemak layout
.
http://ix.io/5Qp .
http://colemak.com/wiki/images/8/80/Colemak_layout_2.png

reserved identifier violation

I would like to point out that identifiers like "_CGDB_H_" and "_INTERFACE_H_" do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

cgdb freezes on exit: Mavericks + gdb 7.7

Hello, I seem to face the same problem as reported in #35 (which as been closed by the reporter without further comment).

When using gdb 7.7 (installed with homebrew and self signed), quitting gdb while debugging works. When using cgdb, quitting while debugging hangs. I then need to hit CTRL-C.

I don't have any .gdbinit
Tell me if you need further information

Selecting a line of text that wraps inserts newlines

If I select a line of text that wraps, newlines are inserted at the point of wrapping. This is inconvenient for copy/pasting gdb output (especially filenames).

cgdb is not working with the color setting in ~/.gdbinit

I tried two color setting for ~/.gdbinit

1. https://github.com/gdbinit/Gdbinit
2. https://github.com/longld/peda

They both add advanced features for default gdb using ~/.gdbinit file, one of them is color/highlight and they are both OK under gdb but not cgdb.

The promopt characters of "(gdb)" and other color settings in cgdb would be something like "[31mgdb$ [0m" not the colors, so, it would be a good idea to add the feature to parse these color settings for cgdb.

Homebrew version (0.6.7) is outdated

Homebrew has the 0.6.7 release, but the most recent release is 0.6.8.

Stuck in TUI

I've accidentally entered TUI by typing 'wh' instead of 'where' in gdb mode.

There seems to be no way to close TUI again - the normal C-x C-a doesn't work. The only option seems to be to close cgdb entirely with ESC :quit, causing me to lose my debugging session.

Also, CGDB unhelpfully (in this case) shows TUIs terminal escape sequences in the console, so TUI doesn't even work.

Maybe cgdb could disable TUI somehow?

Color prompt support

Hello,

It would be nice if cgdb supported color prompt. Currently, I'm having:

Documentation license (GFDL) not compatible with Debian

Our current documentation license (including invariant front- and back-matter from the FSF) is considered "non-free" by Debian:

http://people.debian.org/~srivasta/Position_Statement.xhtml

As it is entirely written by @brasko and myself, we decided to change the documentation license to GPL and be done with it. This will necessitate a new cgdb release for our Debian maintainer.

Add `until` command in CGDB mode

Add window for watchpoints and registers

I'd like to have a "live" view that displays the current values of specified watchpoints and/or register values. It would be useful to not have to check them manually all the time.

Completion of error handling

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ parse
• realloc ⇒ filedlg_add_file_choice

'layout' command breaks cgdb

When I try to use the command layout <some layout>, the cgdb behaves oddly. I could not even quit cgdb.

Hangs on 'quit', under OSX10.8

Using cgdb release 0.6.6, built using homebrew (http://mxcl.github.com/homebrew/).

Verified on two different OSX10.8/Xcode4.4 machines that after any debugging session of any executable, when the "quit" command is given, cgdb hangs and must be explicitly killed. It appears to work normally in all other ways.

If no executable is actually run, cgdb exits successfully when the "quit" command is given.

Attaching gdb to a hung cgdb process suggests that the hang is happening within a call to "select()" (although my cgdb is built without debugging symbols; my next step is going to be to rebuild cgdb manually, complete with debug symbols, and see if I can't get a proper stack trace for where the hang is happening)

Works correctly for me under OSX 10.7 and earlier.

gdb version:
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)

cgdb version:
CGDB 0.6.6
Copyright 2002-2010 Bob Rossi and Mike Mueller.

commands.c:774: bad if test ?

commands.c:774:23: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op]

    if (a != '\n' || a != '\r')

Suggest swap || for &&

cgdb hangs with 100% CPU usage on OS X Mavericks

This happens when allowing the debugged process to continue until termination:

This is the backtrace taken with LLDB (weirdly, GDB is unable to work properly when attaching to a running process on Mavericks):

34851 ttys006    0:06.50 /opt/src/.build/cgdb/cgdb/cgdb sample                                                                                
➤ lldb -p 34851                                                                                                                               
Attaching to process with:                                                                                                                    
    process attach -p 34851                                                                                                                   
Process 34851 stopped                                                                                                                         
Executable module set to "/opt/src/.build/cgdb/cgdb/cgdb".                                                                                    
Architecture set to: x86_64-apple-macosx.                                                                                                     
(lldb) bt                                                                                                                                     
* thread #1: tid = 0x58e822, 0x00007fff841b40cc libsystem_c.dylib`wcwidth + 106, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff841b40cc libsystem_c.dylib`wcwidth + 106                                                                              
    frame #1: 0x00007fff8b67a518 libncurses.5.4.dylib`___lldb_unnamed_function30$$libncurses.5.4.dylib + 632                                  
    frame #2: 0x00007fff8b679fda libncurses.5.4.dylib`___lldb_unnamed_function29$$libncurses.5.4.dylib + 257                                  
    frame #3: 0x00007fff8b67a8e4 libncurses.5.4.dylib`waddnstr + 139                                                                          
    frame #4: 0x00007fff8b6837be libncurses.5.4.dylib`mvwprintw + 166                                                                         
    frame #5: 0x0000000102c967ef cgdb`scr_refresh(scr=0x00007fe83140e130, focus=1) + 399 at scroller.c:320                                    
    frame #6: 0x0000000102c940ca cgdb`if_print(buf=0x00007fe832800000) + 74 at interface.c:1421                                               
    frame #7: 0x0000000102c93ff5 cgdb`if_tty_print(buf=0x00007fe832800000) + 37 at interface.c:1400                                           
    frame #8: 0x0000000102c8a383 cgdb`child_input + 163 at cgdb.c:1279                                                                        
    frame #9: 0x0000000102c899dd cgdb`main_loop + 1613 at cgdb.c:1448                                                                         
    frame #10: 0x0000000102c88f83 cgdb`main(argc=1, argv=0x00007fff5cf78468) + 1139 at cgdb.c:1817                                            

Allow highlighting/underlining/whatever of full lines

For now, the line on which the cursor is only have it's line number colored. When there are several indentation levels it can make it hard to see which line you are on. Currently, the only "solution" I know about is to take the mouse and select the line, so that it highlight.

The same would be useful for the next line to be executed. Plus, the arrow is nice, but it makes the code farther than start of line, which does not help the problem in my 1st paragraph.

Cygwin deprecated function warnings in fs_util

Building on Cygwin produces warnings about deprecated functions:

fs_util.c: In function ‘fs_util_is_valid’:
fs_util.c:59:5: warning: ‘cygwin_conv_to_full_win32_path’ is deprecated (declared at /usr/include/sys/cygwin.h:36)
fs_util.c: In function ‘fs_util_create_dir’:
fs_util.c:97:5: warning: ‘cygwin_conv_to_full_win32_path’ is deprecated (declared at /usr/include/sys/cygwin.h:36)
fs_util.c: In function ‘fs_util_get_path’:
fs_util.c:152:5: warning: ‘cygwin_conv_to_full_win32_path’ is deprecated (declared at /usr/include/sys/cygwin.h:36)

This should probably be addressed before the functions become obsolete.

source window jump to function definition given symbol

It would be convenient if I could force the source window to jump to an arbitrary function definition given a symbol. GDB already seems to have the required source location information

$ info line myfunction
Line 12 of "/made/up/file.cpp"
....

No matter what the current view of the source window is, I would like a command that displays the code for 'myfunction'.

Disassembly window/mode

It would be handy to be able to have a view similar to the source window, only for instructions. As it is, I'm manually figuring out the memory range and running the disassembly every few instructions (it's really tedious).

I understand it may not be feasible to get the full disassembly with all the scrolling that the file-view offers, but even something like the four instructions before and twelve instructions after %eip would be pretty handy for what I'm doing now.

Jumping in source window

Is there any command for me to jump in source window, such as jump to the next/previous breakpoint, jump back to the currently executing line when that line is not in sight.....

cgdb not showing source code

I'm trying cgdb with the following configuration:

• Ubuntu 12.10 64bit
• cgdb 0.6.7 compiled from source
• gdb 7.5-ubuntu

And everytime I try cgdb, no matter if remote or local debugging, it does not show source code. However, gdbtui and gdb "list" comand are able to show the source code perfectly

Is there any kind of issue with this version of gdb?

Thank you

CGDB in TMUX

Hi,

I found that CGDB's TTY mode does not work well in TMUX.
It is broken after moving the curse.
Thanks!

Trent

Add arrow to improve visibility for SelectedLineNr

I would like to recommend adding something arrow similar to the arrow seen on the current execution line.

Currently, the highlighting for the selected group defaults to using A_BOLD with normal text which I find leads to contrast problems on several display/terminal combinations I've tested (including my workstation at work) because \033[0;37m and \033[1;37m aren't sufficiently different to be obvious in the presence of other visual noise (e.g. syntax-highlighted code). Moreover, when your current line number has any other highlighting style (like a breakpoint), the indication of your current line disappears.

Another possibility I considered was changing the default colour to cyan (\033[0;36m) or magenta (\033[1;35m), but this doesn't work for monochrome terminals or address the alternate styling issue, so the arrow seems like an adequate compromise. On the topic of monochrome mode, it's probably worthwhile to differentiate them by using different characters. Maybe use the ACS_DIAMOND, ACS_BULLET, or 187|A_ALTCHARSET?

(Note: I haven't used cgdb with a light background; things may be different there.)

Allow jumping to a precise line in dialog mode

Everything is in title.
For now, as far as I can see, it is only possible to jump to start of file, end of file, or line containing a regex.
It would be really useful to have vi-like commands to move into the file, like 125gg to go to line 125, or 10j to move 10 lines toward eof.

Build error on FreeBSD 9.1

gcc -DHAVE_CONFIG_H -I. -I../..      -g -O2 -MT pseudo.o -MD -MP -MF .deps/pseudo.Tpo -c -o pseudo.o pseudo.c
pseudo.c: In function 'pty_open':
pseudo.c:332: error: 'I_PUSH' undeclared (first use in this function)
pseudo.c:332: error: (Each undeclared identifier is reported only once
pseudo.c:332: error: for each function it appears in.)

I think it is because pty_open assumes that my system supports STREAMS, but it doesn't.

First line of a file is always displayed as if it was executed

Everything is in title.
A line should not been marked as next executed if it is wrong. In case no line in a file is the next executed one, no line should be marked as next executed at all.
I would consider this as a bug.

On the other hand, it might be useful to mark the next line to be executed of a file even if it is not the deepest one in the callstack.
For example, imagine a project with 2 files foo.c and bar.c. A debugging sessions ends with a backtrace like this:

0x0123456798 in bar() at ~/example/bar.c:24
0x9876543210 in foo() at ~/example/foo.c:42

when the displayed file is foo, the line 42 should be be marked as next executed (since it is in the callstack), and when it's bar.c which is displayed, then line 24 should be marked.
This, is a feature request linked to the bug. Now, I don't really consider this an important feature, and I don't know enough about cgdb's code to do it myself.

.gdbinit breakpoints executed but not shown on GUI

When you set a breakpoint, the line number on the cgdb GUI turns red.

I set a breakpoint and saved it using "save breakpoints .gdbinit". .gdbinit is executed automatically by gdb on startup to restore a previous debugging 'session'. Upon starting cgdb, the gdb prompt at the bottom reports that the breakpoint from .gdbinit has been set, but the GUI is not updated as if no breakpoint is set.

Typing any command (or even just an empty one) at the gdb prompt will update the GUI view at the top, reavling the magnificent breakpoint in its red glory.

help2man required

https://github.com/cgdb/cgdb.github.com/blob/master/index.html indicates that readline and ncurses is required but makes no reference to help2man. If help2man is missing the build will not start.

I've not found a flag to configure that disables the check BUT there is a variable that can be set to trick configure.

env HAS_HELP2MAN=yes sh ./configure --prefix=/usr/local

Make will fail on the man pages BUT the cgdb exe/binary does get created correctly:-)

Colored output of the terminal program is displayed without color, with control sequences visible

I have a terminal program that senses if the standard output is a terminal (based on isatty(1)), and automatically prints control sequences when it is a terminal.

The problem is that when run under cgdb, for some reason, isatty(1) returns 'true', but output isn't printed as colored, and control sequences are printed as clear text.
When run under just gdb, output is colored.

This test case demonstrates this problem:

#include <unistd.h>
#include <stdio.h>

main() {
  if (isatty(1)) {
    printf("\033\[31mWe are on the terminal, this is a red text\033\[m\n");
  } else {
    printf("We are not on the terminal, this is a black text\n");
  }
}

I run on kde4 konsole terminal, if this matters, on FreeBSD 9.

Terminal cursor appears when cgdb window is maximized.

http://i.imgur.com/wzibz9O.png

Can It support lldb(clang)?

It's support gdb but no support lldb, Want use it with lldb.

segmentation fault when source window size exceeds length of displayed source file

cgdb segmentation faults when the source window size exceeds the length of the displayed source file. The seg fault has been reproduced on linux (RHEL6) and OS X (10.6.8).

Backtrace from a core dump when the size of the source window is increased by typing "=":

(gdb) bt
#0 0x0000003a406480ac in vfprintf () from /lib64/libc.so.6
#1 0x0000003a406ffa80 in __vsnprintf_chk () from /lib64/libc.so.6
#2 0x0000003a52015c99 in _nc_printf_string () from /lib64/libncurses.so.5
#3 0x0000003a5201159f in vwprintw () from /lib64/libncurses.so.5
#4 0x0000003a520117a8 in wprintw () from /lib64/libncurses.so.5
#5 0x000000000040d71f in source_display (sview=0x127c450, focus=1) at sources.c:732
#6 0x000000000040a2ac in if_draw () at interface.c:432
#7 0x000000000040a6fe in if_layout () at interface.c:534
#8 0x000000000040bb61 in source_input (key=61) at interface.c:1066
#9 internal_if_input (key=61) at interface.c:1347
#10 0x000000000040bb78 in if_input (key=61) at interface.c:1387
#11 0x000000000040381f in user_input () at cgdb.c:842
#12 user_input_loop () at cgdb.c:893
#13 0x0000000000404ca5 in main_loop (argc=, argv=) at cgdb.c:1362
#14 main (argc=, argv=) at cgdb.c:1737

(gdb)

Backtrace from a core dump when the terminal running cgdb is resized:

(gdb) bt
#0 0x0000003a406480ac in vfprintf () from /lib64/libc.so.6
#1 0x0000003a406ffa80 in __vsnprintf_chk () from /lib64/libc.so.6
#2 0x0000003a52015c99 in _nc_printf_string () from /lib64/libncurses.so.5
#3 0x0000003a5201159f in vwprintw () from /lib64/libncurses.so.5
#4 0x0000003a520117a8 in wprintw () from /lib64/libncurses.so.5
#5 0x000000000040d71f in source_display (sview=0x17d3530, focus=0) at sources.c:732
#6 0x000000000040a2ac in if_draw () at interface.c:432
#7 0x000000000040a6fe in if_layout () at interface.c:534
#8 0x000000000040ae51 in if_resize () at interface.c:553
#9 if_resize_term () at interface.c:573
#10 0x0000000000404ba9 in cgdb_resize_term (argc=, argv=) at cgdb.c:1274
#11 main_loop (argc=, argv=) at cgdb.c:1405
#12 main (argc=, argv=) at cgdb.c:1737

(gdb)

cgdb hangs when using gdb 7.6.1 on Mac

Hello,

On my OX 10.8.5, I installed both cgdb and gdb 7.6.1 with brew.

Launching cgdb with gdb 7.6.1 just hangs the process.

Forcing cgdb -d /usr/bin/gdb to use stock gdb 6.3.50-20050815 works.

"CGDB had unexpected results" when home is readonly

When the home directory has no user write permission (done for security reasons and to prevent applications from writing unnecessary config files there), cgdb prints an annoying "CGDB had unexpected results" warning on exit. Because ~/.tgdb exists and can be written to, there is no reason for cgdb to complain, so it should not.

SelectedLineNr default style is not distinguishable on some terminals

SelectedLineNr defaults to being a bold white, which looks very similar (if not identical) to the other non-selected lines in the window (which are non-bold white). We should probably choose a more distinct default style for this element.

The cgdb display needs to update its contents when gdb braches control to exec.

This isnt really a critical bug persay, but it would be nice to have the new source file shown in the cgbd display right after a call to exec with the 'follow-exec-mode same' option set. Currently we have to drop to gdb's CLI and set a breakpoint on main to update the display to show the new source file.

No way to find next in the file dialog

I just installed CGDB 20151105 from master 3a710f9

In the docs it says that N or n will go forward/back in the search. This doesn't appear to work.

If I'm searching for the header file something.h but I have something.cpp somethingelse.cpp and something.h
I start the search by typing /something and it matches something.cpp
I type ESC then n and nothing happens.

How do I skip to the next match?

cgdb freezes at startup (on ARM)

cgdb freezes on startup after reading symbols:

cgdb terminal output:
GNU gdb (GDB) 7.6.1-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/kraiskil/hello...done.

Backtrace:
(gdb) bt
#0 0xb6e5e4fc in select () at ../sysdeps/unix/syscall-template.S:81
#1 0x0000af5a in main_loop () at cgdb.c:1338
#2 main (argc=, argv=) at cgdb.c:1737

Only a "kill -9" makes it stop. This seems an ARM issue, I use cgdb extensively (my favourite UI to gdb, thanks!), and have seen it on at least two ARM boxes, never on a x86 box. Could be it is a race that is triggered because ARM is generally slower than x86, don't know.
The testprogram cgdb is debugging is a "int main(void){return 0;}, compiled with 'gcc -O0 -g hello.c -o hello'. The hello-program debugs fine on plain gdb on the same system.

Can’t use with programs that read stdin

If I debug a program that reads stdin (fgets or readline) with cgdb, the first command to read a line gets "stuck" – pressing enter doesn’t do anything (besides inserting a newline in the console). If I CTRL-C, I can see that it’s stuck in the syscall:

Program received signal SIGINT, Interrupt.
0x00007ffff78bb6e0 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.

test script: https://gist.github.com/lucaswerkmeister/7657641

This happens on both my 32-bit Funtoo netbook and my 64-bit Mint main PC.

Chinese support in LinuxMint error

I have recently use LinuxMint and installed CGDB by command:

apt-get install cgdb

and CGDB version 0.6.6 is installed. But when I try to debug my program with Chinese comment, CGDB shows wrong Chinese charaters in the code window:

and I open the gdb to debug it, and it goes all right:

and my locale is:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

also I tried to set LC_ALL to "C" or "zh_CN.UTF-8" or "", It doesn't work.
But CGDB in Ubuntu 10.04 and 12.04 don't have this problem.

Allow for a Vertical Split

A option should be provided to allow for users to render the UI in a vertically split manner. This would permit for the full screen on larger monitors and make more sense on wide-screen displays.

Open file dialog extremely slow on network drive

User reported that cgdb will thrash for 20+ minutes at 100% CPU after hitting 'o' to open a file where the sources are hosted on an NFS drive. Running info sources in gdb completes in a few seconds, so this is likely a bug in cgdb.

See discussion here: https://groups.google.com/forum/?fromgroups=#!topic/cgdb-users/BtI9ze4g9Ts

GDB Prompt Hangs after Pressing Tab in a "Command List"

Bug Behavior:
Like the image shows, the GDB prompt will hang(no longer accept any input) after I pressed [TAB] in a "command list", which is attatched to a hardware watchpoint by setting a watchpoint on a strcuture "confinfo", then type "commands 2".
Details:
The situation here is that I can still return back to the source code window by using [ESC], but after I was brought back to the GDB prompt by typing [i] the prompt will not accept any input because I pressed [TAB] to try to complete "printf"' so the only thing I can do is to quit by tying ":quit" in the source window.
Platform:
x86-64 Archlinux running 4.1.10-2-lts kernel
CGDB 0.6.8 from default pacman repository
Thank you for looking into this issue!

Cannot open files with '#' in path

Some of the executables I debug have absolute paths to source files embedded. Many of these absolute paths contain '#'. When I use filedlg to navigate to such a file, and select it with the Enter key, the file does not open, and I'm left with the file that was previously open (if any) in the top pane.

These filenames have to be quoted when being sent via tgdb as server list filename:1
E.g. server list "filename:1"
or server list "filename":1

I did the latter and it seems to work, in this sort of hacky workaround in filedlg.c (probably better done in the tgdb layers?)

int filedlg_recv_char(struct filedlg *fd, int key, char *file) {
...
    switch ( key ) {
...
       /* User selected a file */
        case '\n':
        case '\r':
        case CGDB_KEY_CTRL_M:
            snprintf(file, MAX_LINE, "\"%s\"", fd->buf->files[fd->buf->sel_line]);
            return 1; 
...
}

Bug report: can't deal with scanf() function

A simple program:

#include <stdio.h>

int main(void)
{
        int i;
        printf("Enter a number:\n");
        scanf("%d", &i);

        printf("The number is: %d\n", i);

        return 0;
}

After compiling sample.c into sample, the sample cannot can be debugged under cgdb but is OK under gdb, after the scanf() line, you type a number, the binary will go on under gdb, but nothing will happen after that if you are using cgdb and you have to type C-c to exit to (gdb) prompt character.

I don't konw if there are other functions which cannot be parsed by cgdb, scanf() is the only one occurred to me BY NOW.

cgdb on Mac OS X 10.9 with cgdb 7.6.1 freeze at end of process

I use Mavericks with the homebrew version of gdb 7.6.1. cgdb freeze at end of the debugged process, but if I use gdb standalone, it does not freeze.

Add support for UTF-8 identifiers

Here's valid example in GO language with UTF-8 identifiers:

package main
import "fmt"

func main() {
    var пример = "aaa"
    var 世界 = "bbb"
    fmt.Println(пример, 世界)
}

This is output of GDB session

Breakpoint 1, main.main () at a.go:4
4 func main() {
(gdb) n
5 var пример = "aaa"
(gdb) n
6 var 世界 = "bbb"
(gdb) n
7 fmt.Println(пример, 世界)
(gdb) n
aaa bbb
8 }

This is output of CGDB session

func main() {
var M-PM-?M-Q~@M-PM-8M-PM-<M-PM-5M-Q~@ = "aaa"
var M-dM-8VM-gUL = "bbb"
fmt.Println(M-PM-?M-Q@M-PM-8M-PM-<M-PM-5M-Q~@, M-dM-8VM-gU~L)
}

Readline error lacks details

configure: error: CGDB requires GNU readline 5.1 or greater to link.
  If you used --with-readline instead of using the system readline library,
  make sure to set the correct readline library on the linker search path
  via LD_LIBRARY_PATH or some other facility.

It would be nice if this error included the version of readline detected (I think I have 6.2.4 installed), as well as some useful URLs or commands to install it.

Debugged programs should not detect a terminal, until terminal sequence handling is fixed

Currently terminal sequences are printed w/out being interpreted, trashing up the output.

I understand that this may be difficult to fix. So you just need to turn off the bit returned by "isatty(fileno(stdout))".