Please don't reply I should use ddd, nemiver, emacs, vim, or any other front-end, I just prefer gdb as it is, but would like to see its output with some terminal colors.
.gdbinit
You can tweak your ~/.gdbinit to have colors. You can use mammon's .gdbinit which is available here:
https://github.com/gdbinit/gdbinit
You can tweak it as much as you want too. I found this thanks to this SO answer. Here's the kind of output that you can obtain:
A GitHub repository is also available: https://github.com/gdbinit/Gdbinit
On a side note, the same idea was also applied to lldb.
GDB Dashboard
Following the same concept, GDB Dashboard provides a modular visual interface for GDB in Python.
(void)walker
Another similar project uses GDB's Python support to provide more extensibility, so this is worth checking out: https://github.com/dholm/voidwalker
#dholm also provides his own .gdbinit inspired from the previous one.
pwndbg
Some projects provide a set of useful functions, including improved display. This is the case for PEDA or pwndbg. The latter gives the following description:
A PEDA replacement. In the spirit of our good friend windbg, pwndbg is pronounced pwnd-bag.
Speed
Resiliency
Clean code
It provides commands to support debugging and exploit development similar to the ones from PEDA, and better display (although this is not the main focus of the project). The software is still under development, and has not been properly released yet.
voltron
The project description states:
Voltron is an extensible debugger UI for hackers. It allows you to
attach utility views running in other terminals to your debugger (LLDB
or GDB), displaying helpful information such as disassembly, stack
contents, register values, etc, while still giving you the same
debugger CLI you're used to.
You can modify your .gdbinit to automatically integrate it. However, the display itself is outside of GDB (e.g. in a tmux split).
GEF
GEF is another option, and it is described as:
It is aimed to be used mostly by exploiters and reverse-engineers, to
provide additional features to GDB using the Python API to assist
during the process of dynamic analysis and exploit development.
It's not colours, but consider gdb's text gui. It makes a vast difference to how usable gdb is.
You can launch it with:
gdb -tui executable.out
Screenshot:
As you can see, the main features are:
shows what line of the source we are on and surrounding lines
shows breakpoints
I know you did not want a frontend.
But how about cgdb it is very close to gdb,
it is textmode but has a source window above with syntax highlight on the code.
New in upcoming GDB 8.3!
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/NEWS
Terminal styling is now available for the CLI and the TUI. GNU Source
Highlight can additionally be used to provide styling of source code
snippets. See the "set style" commands, below, for more information.
It is possible to greatly enhance the appears of gdb through the use of colors. This is done via any of the following methods:
Colorized prompt via the "set prompt". E.g., make the prompt bold and red:
set prompt \033[1;31m(gdb) \033[m
or make the prompt a new shape, bold and red:
set prompt \033[01;31m\n\n#####################################> \033[0m
Colorized commands via hooks
Colorized syntax highlighting of the "list" command.
All examples are available at the following blog posts written by Michael Kelleher:
"Beautify GDB", May 12, 2010 (via archive.org)
"Experimental GDB syntax highlighting", May 15, 2010 (via archive.org)
cgdb is much better than gdb -tui
#into .gdbinit
shell mkfifo /tmp/colorPipe
define hook-disassemble
echo \n
shell cat /tmp/colorPipe | c++filt | highlight --syntax=asm -s darkness -Oxterm256 &
set logging redirect on
set logging on /tmp/colorPipe
end
define hookpost-disassemble
hookpost-list
end
define hook-list
echo \n
shell cat /tmp/colorPipe | c++filt | highlight --syntax=cpp -s darkness -Oxterm256 &
set logging redirect on
set logging on /tmp/colorPipe
end
define hookpost-list
set logging off
set logging redirect off
shell sleep 0.1s
end
define hook-quit
shell rm /tmp/colorPipe
end
define re
hookpost-disassemble
echo \033[0m
end
document re
Restore colorscheme
end
Warning: Buggy. No TUI support, 'user-mode' hack.
Found the main part here
and modified it a bit. Needs highlight, c++filt. If colors get messed up issue re command.
Neat, I just found this hack using colout: https://github.com/nojhan/colout/blob/master/colout/example.gdbinit
I wanted to highlight as follows: emphasise the lines of a stack trace which belong to my source files (rather than libraries).
The solution was to use gdb-python (on MSYS; on Linux typically gdb comes with Python built-in already?), hook backtrace, use
python stack_trace = gdb.execute('backtrace', False, True')
Then process stack_trace with Python's regexes, and print them out. Bold and other colours are achieved by a function like this:
def term_style(*v):
"""1 is bold, 30--37 are the 8 colours, but specifying bold may also
change the colour. 40--47 are background colours."""
return '\x1B['+';'.join(map(str, v))+'m'
#Use like this:
print term_style(1) + 'This will be bold' + term_style(0) #Reset.
print term_style(1,30) + 'This will be bold and coloured' + term_style(0)
print term_style(1,30,40) + 'Plus coloured background' + term_style(0)
Another good combination of colors is given by this configuration. It renders inspecting the backtraces a lot easier. To use it, just save that file as ~/.gdbinit and run gdb normally
you can get whatever colors you want;
# gdb
(gdb) shell echo -en '\E[47;34m'"\033[1m"
...
anything is now blue foreground and white background
...
(gdb) shell tput sgr0
... back to normal
Related
I need to disassemble some C code, but I want to also show the source lines mixed in with the assembly code. The issue I have is that I'm using gdb through the MI interface, which calls disassemble (or equivalent, perhaps -data-disassemble?), and I have no control over the options sent with the command. If I did have access to the command, I could probably just use
-data-disassemble ... -- 1.
I've tried making a user-defined command, e.g.:
define dis
disassemble /s
end
but I don't know how to force using that command through gdb/mi. I also tried making an alias, but it creates a naming conflict ("Alias disassemble is the name of an existing command") and probably wouldn't work anyway because of the MI connection.
I'd like to just add a line to my .gdbinit file that forces the /s option to be a default for disassemble, but I can't find any documentation that shows how this can be done.
As a side note, I'm trying to accomplish this in MSVC 2019, and I can sort of do it manually using the instructions from Microsoft's MIEngine custom command doc. But this doesn't go through the usual gdb/mi interface, and just dumps text into the Command Window. I was able to set disassembly-flavor intel, which works in changing the assembly into Intel format, so it seems like what I want to accomplish is at least plausible.
I currently use vim/byobu-tmux to multiplex between a command line (cmake/gcc) and a vim session.
Is there a way to do the following directly within the vim session?
Compile within vim (I currently use a cmakedbg bash alias in a command line/bash session)
Jump to files/location where the compile has failed
all within vim, that would save me a lot of time.
Did you try
set makeprg=cmakedbg
Then
:make
should compile and if it fails it should automatically jump to the error (while :make! would compile without jumping to the error). This works usually, but might need some tweaking depending on the setup.
If you need to source .bashrc before cmakedbg works, you can make the shell interactive by
:set shellcmdflag=-ic
However, I always had problems with that. I know it's working for some people, but when I try that, vim is stopped by the interactive mode. I can get it back by typing fg, but that's not what I want.
I think the best way to do it is to set up a function in vim and do it without .bashrc.
The reason why I'm asking this, is because I'm coding in C++, in putty/ssh and I like the fact that I can code from pretty much everywhere without having to install anything.
So I'd like to have something that could help me debugging (viewing LIVE value of a variable, breakpoints, etc)
If you think that there's no such thing in this world, is there any good technique I could use to debug in command line?
Thanks
I've used gdb for command line debugging in the past with success:
http://www.gnu.org/software/gdb/
A decent tutorial can be found at:
http://www.cs.cmu.edu/~gilpin/tutorial/
vimgdb will give what you want. I've used it for about one year. The most interesting feature is:
Hightlight current line
List item
Can show disassembly code
Step into, Step over
inspect variables, memory address
Run all the underlying gdb command is possible
And, of course, set breakpoint, conditional breakpoint etc.
Highly customizable by vim key mapping and scripts.
Actually I use checkinstall to make an rpm for it, and installed it everywhere when I need to debug on the box.
I think it have the most important features I want from a visual debugger.
Have you tried gdb ? That's pretty much the command line debugger, but it's no vim plugin.
You have a script to do that: http://www.vim.org/scripts/script.php?script_id=1954
In my humble opinion, Vim is not designed to do such things and it is a bad idea to do so.
GDB, at least as it's configured by default on my Ubuntu 9.04 box, doesn't handle multi-line statements well. When I'm stepping through code, GDB only displays the last line of the current statement, even if that statement spans multiple lines.
I'm aware that I could use DDD or emacs as a frontend for GDB, but I'd prefer to solve this problem within GDB, if that's possible.
Does anyone know if there's a way to get GDB to do the right thing here?
How about running GDB with the text user interface?
gdb -tui
It makes a world of difference to the ease of use of GDB.
I'm afraid the answer is "no, there is no way to get gdb to do what you want".
The line info in the symbol tables associates each code instruction with a single
source line (not a source statement). gdb has no way of knowing that several
source lines are associated with the same source statement.
For example, I'd like to not indent namespaces in C++ code, but the prefpane doesn't seem to have any place to make a decision of this granularity. Is there some hidden config file or something? Or am I just out of luck?
Apple's XCode documentation contains a full list of user preferences, many of them that don't have a corresponding UI. I'm not seeing anything that is namespace-specific however, so I think you might be out of luck.
However, I thought I'd pass along the preferences list in case it's useful.
I've also attempted to do this.
The answer is that whoever did the code formatting in XCode appears to be completely unaware that there are languages other than Objective C, or coding styles other than Apple's.
Here's a list of things that one would want to do that can't be done in XCode.
Indent public: or private: just one space.
Indent namespaces zero spaces.
Alternate indentation for arguments NOT relative to the opening parenthesis.
The last one needs a little discussion. Sometimes, a function or method name can be quite long, as well as its first argument, so you want also to be able to indent like this:
someExcitingClass->AVeryLongMethodNameTraLaLaLaLa(
someLongExpressionOrVariableNameGoesHere,
anotherNameHere);
Of course, you might want to be extracting subexpressions to make the line shorter, but in real-world code this comes up all the time, and creating subexpressions just to fit everything into a reasonable line length is annoying.
It's a terrible shame and I really have no idea what to do. I personally write in emacs and only dip into XCode as a build system but :-D that's not for everyone.
As the Xcode indenter uses just the lexer, and not the AST, you can 'fool' the formatting by defining away the curly braces.
I have:
#define NAMESPACE_OPEN(_name) namespace _name {
#define NAMESPACE_CLOSE(_name) }
#define dsmsg_namespace_open NAMESPACE_OPEN(dsmsg)
#define dsmsg_namespace_close NAMESPACE_CLOSE(dsmsg)
i.e., a generic 'NAMESPACE_OPEN/CLOSE' define, and a define specific to my most-used namespace 'dsmsg'. Then, whenever I want to open the namespace, I use
dsmsg_namespace_open
... code ...
dsmsg_namespace_close
Ugly hack, but I quite like having a specific, named 'close'
I bypass Xcode's indenting altogether, and have a user script that calls uncrustify on the currently displayed document.
#!/bin/sh
#echo -n "%%%{PBXSelection}%%%"
uncrustify -q -c ~/.uncrustify/sample.cfg -l oc+
#echo -n "%%%{PBXSelection}%%%"
Notes:
uncrustify must be in your PATH
you may need to adjust the location of your config file
if you want to have the new code selected in Xcode, uncomment the two echo statements (this can also be used to make a "Format Selection" script, rather than "Format All"
Script Settings:
Input:Entire Document
Directory: Home directory
Output: Replace Document Contents
Errors: display in alert
As of Xcode 4.3.1 no custom namespace indent options are available, however I overcame this irritation by navigating to Preferences->Text Editing->Indentation and disabling "Syntax-aware indenting".
Another possibility is to use Articstic Style (astyle). A tutorial how to integrate astyle into XCode using automator and services can be found here: http://eatmyrandom.blogspot.com/2011/03/xcode-astyle-part-2-for-xcode-4x.html and http://youtu.be/d8bbE6_OHGc