I can't find a way for cgdb to disassemble a binary and show the assembly code with the current instruction in the code window. Is this possible and what command should I use? I'm using Mac OS X and got cgdb from the homebrew repository.
display/i $pc shows disassembly always for the current instruction, in the console window.
To show disassembly for more instructions, prefix i with the number of instructions.
For example,
display/5i $pc
shows disassembly always for the next 5 instructions.
A recent update (Feb 2017) to cgdb makes it possible to do this. You will need cgdb version 0.7.0 or newer. (At the time of writing this is the latest release). You may need to compile this from source yourself given how recent it is.
More details on adding disassembly support can be found here:
https://github.com/cgdb/cgdb/issues/44
To view the disassembly in cgdb hit esc and type :set disenter.
To go back to the source (if available), repeat this, except type :set nodis.
I am working on MacOS to defuse a binary bomb and find "gdb -tui" will be helpful. Than I found "cgdb" can make code colorful. But what we want to see is show disassembled code on the code window, the answer above only show the code line by line or only changeless lines.
Unfortunately, I find a post said that "the cgdb does not support assembly display (yet)."
https://groups.google.com/forum/#!topic/cgdb-users/E-jZCJiBAQQ
Sorry guys, cgdb does not support assembly display (yet). It's a
frequently requested feature, and when we get a little more time to
work on cgdb we will probably add this.
Starting cgdb with the -tui option is a bad idea -- the TUI (text user
interface) is an alternative curses interface to gdb, not a part of
cgdb. It will not play nice with cgdb.
Mike
--
Mike Mueller
Well, it's 12/11/15, but it seems still couldn't show the assembly code on code window like gdb in tui mode.
Related
I'm a C++ newbie (up to 2.4a on www.learncpp.com) and I'm having trouble debugging in codeblocks. The terminal that opens up when I start debugging says "warning: GDB: Failed to set controlling terminal: Operation not permitted
" and whenever I try to do something, an error appears in the bottom right saying that it couldn't open some file called fileops.c
Here's an image:
GDB is the GNU Debugger. Rest assured,
GDB is not broken.
The pesky warning: GDB: Failed to set controlling terminal: Operation not permitted
has appeared forever in Code::Blocks when you start debugging, due to the way
in which C::B invokes GDB. It is harmless and you can ignore it.
The GDB message fileops.c: No such file or directory appears because
you trying to step into a function that is defined in fileops.c, which
is a source file of the GNU C Library. You cannot step into such functions
because the source code of the GNU C Library that is linked with
your program is not available to GDB.
In general, the source code of any system library that your program is
linked with will not be available to the debugger and similar messages will
appear if you try to step into functions defined in those libraries.
You have to step over those functions and almost always you can do so with a good
will, because the bugs you are looking for are not there. They are in your source
code, which is available to the debugger, and plodding down through all
of the library calls, even if you could, would likely keep you debugging into
old age.
In short, there is nothing the matter. Just step over the functions that you
didn't write.
Debugger shows me dissassembler code, while i am trying to step over the instructions of my program.
Using lldb under QtCreator.
Interesting thing is: debugging works fine, if i use it without QtCreator (via terminal)
Small projects seems to debug normally... So I've try to add peaces of my project gradually to small one.
I've found a peace of code, that resulting to crash:
QVector<myClass>::contains();
But if i try to make an empty project only with this realisation, problem disappeared.
I've lost about a week, trying to solve it.
Any ideas, what can go wrong?
EDIT:
Well, QtCreator still using GDB instead of LLDB, that i refer it to...
Looks like bug
I'm studying "Compilers" and we work on Flex to program.
I create *.lex files (with any editor), convert them into lex.yy.c via flex, and then compile to a.exe using gcc.
Writing lex code in an editor like Notepad/Codeblocks/... is not only hard because everything is just BLACK, but also there is no debugging system.
The gcc compiler does tell about errors, but what i'm looking for is something i can go line by line with the code (in runtime) and see what's going on with the variables. Like the command F10 in Visual Studio.
Does anybody know a suitable program for this? Thanks alot
Concerning hightlighting, using gedit(The default GUI editor on Ubuntu and some other Linux variants) or even vim will provide that for you, you don't have to use plain notepad.
As for the debugging, yes there's what's called the GNU Debugger (aka GDB) which allows you to do typical debugging jobs after you've compiled your code, you can step line by line and examine certain variable values.
Before doing that, first compile your program with the gcc flag -g to add debug symbols to the complied result, then run gdb yourProgramName, this will run GDB and you'll be able, using certain commands, to do whatever debugging tasks you want.
I once wrote a little guide to help people get started with GDB, it might be useful.
Is it possible to get a complete disassembly (which can act as input to an assembler) of an executable?
When I use otool -tV a.out I get to see only the text section. Other sections like data aren't visible.
When I use gdb, the disassemble command requires a start and an end address. However I do not know how to find out the start and the end address of a binary (say a.out).
I'm trying to disassemble an executable, tinker with the assembly code and then reassemble it.
Is that possible?
It'd also help if one can find out the names of all the sections in a binary.
Try using this command, i remember using it sometime back:
otool -tvV a.out
On Mac, you can install (possibly by homebrew) binutils that includes gobjdump. You can disassemble any binary program once installed. It's open and free.
You can use the Hopper Disassembler
quote:
Hopper is a reverse engineering tool for the Mac, that lets you disassemble, decompile and debug your 32/64bits Intel Mac executables.
It costs $59, but you can download a demo to check if it gets the job done first.
EDIT
It seems you can achieve this with otool as well, according to the manual.
.B -d
Display the contents of the (_^_DATA,_^_data) section.
Also have a look at this short blog post (archive link, original is gone) that describes the mentioned use of otool, and how you can use objdump as mentioned by #Sjlver.
On linux, you can try to use objdump -D myprog
Note that this will work only if the program does not contain irregular control flow. Especially malware is often obfuscated, e.g. by inserting spurious bytes that are then jumped over.
If you're targeting this kind of programs, I've heard that one of the best products to use is IDA pro.
I'm working on writing an OS and I'm running into problems trying to debug my code. I'm using GDB to connect to Bochs' GDB stub to "remotely" debug my kernel. Connecting works fine, as does loading debugging symbols from the kernel file. I set a breakpoint for the kmain function, which is successfully located, and the debugger breaks correctly (inside my kernel). However, I can't "step" or "next" through my code, nor can GDB apparently determine which line of code is the current line.
When I try to "step", I get the following message: "Cannot find bounds of current function". This is the only error message I get at any point.
My code is being compiled in GCC with the -g flag (I've tried other types of debugging information using GCC options; none have worked.) I have tried looking through the GDB manual , as well as searching for the answer, and I'm totally stumped. Any help would be amazing.
Thanks!
Well, I got debugging working, but I had to switch emulators. I was able to get GDB working with Qemu, even though I also had problems doing that. To get GDB to connect to the Qemu gdbserver, I had to pass the following option to Qemu: "-gdb tcp::1234,ipv4". Took me forever to figure that out... Debugging works perfectly now!
Googling throws up "This is because when you attached to gdbserver, the process under
debug has not completed the C start-up code" http://www.cygwin.com/ml/gdb/2005-03/msg00237.html... http://www.bravegnu.org/gnu-eprog/c-startup.html describes the process for when you are coding for embedded devices, maybe this will help?
If you find the answer please post here as I'd like to know what the solution to the problem is too.
I don't know why but bochs with gdb-stub enabled seems to be picky with the config options. On some system following options will break it:
--enable-x86-64, --enable-vmx