A recent change to run-clang-tidy.py means that the underlying clang-tidy command is now always run with -use-color. The question is how to disable that.
I use this script with the Sonarqube Community C++ plugin and this cannot handle the extra colourisation characters - FTR it reports that all the files cannot be found in the associated repo.
I have tried adding extra parameter -config '{"UseColor":false}' but it made no difference.
Short term, I will probably locally modify the python script. Long term, I wonder if there is a better approach?
This issue is now fixed in LLVM's main branch and should be resolved in the next release. The old default behavior has been restored and you'll be able to explicitly opt in or out of colored output using the -use-color option.
As a short-term fix, you can strip out the ANSI escape characters that enable colored output yourself. See Removing colors from output for instructions.
I would like to write a bat script which call gdb. I want to use script variables in debugging session (like paths, variable names etc.) For example name and location of the config, address ranges to dump or even command.
Is there easy way to do that? I know that there are gdb scripts but I'm not sure how to do that in easy way.
I see that I can access to script variables with "environment" specifier but I can't use it in other way than show and modify this data.
Without considering the sense of this example I would like to have behavior like below.
Bat script:
SET MY_COMMAND=run
SET MY_COMMAND2=quit
SET MY_FUNCTION=main
:: GDB CALL ??
And expected gdb behavior:
break MY_FUNCTION
MY_COMMAND
MY_COMMAND2
Maybe this will be solution for you:
~/.gdbinit
You can put gdb commands there, and whenever gdb is started it will execute them.
Well, in fact, in your case it would be easier to use another approach:
--command=FILE
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.
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.
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