I have a function that I am trying to examine. I want to find all callers of this function, but there are a few issues:
I am doing this to understand the code because I did not write it, but I need to know exactly how it behaves
It runs through the STL beforehand, so I can't just use something like callgrind to get it's immediate callers
There is a stack trace of 10+ function calls until you get to actual code that is not in the STL that caused this function to be invoked. But those STL entry points vary, as it is a compare function and calls for is_equal go through a different sequence than those that go through not_equal, etc. I will need to do this for at least 10+ different functions, and I want to streamline this as much as possible.
I want a tool that can dump each unique, full backtrace each time the function is called. Does anybody know a tool that can do this?
I am using gdb and c++ on Ubuntu 14.04.
You can make gdb execute a series of commands each time a given breakpoint is executed, e.g.,
break someFunction
commands
bt
continue
end
The feature is mentioned in gdb scripting: execute commands at selected breakpoint, which has a link to the online documentation for gdb 5.1.7 Breakpoint Command Lists
Related
Most debuggers with GUI have a useful function run to cursor. Is there any similar way of doing this in gdb?
I'm talking about assembly mode debugging (without source code).
For example, it currently break at: 0x400000, I'd like to run to 0x400100, there're lots of instructions between them. To do this, I have to:
set breakpoint at 0x400100 with b *0x400100,
continue with c
delete breakpoint with d ...
It is lots of typing, and I need to do this frequently. Any simpler way of doing this?
You are looking for either "until" or "advance" command.
Details in GDB manual chapter Continuing and Stepping.
If stopping on frame exit is problematic, you can still use tbreak, which sets temporary breakpoint, which is automatically deleted once it is hit.
This is homework. Tips only, no exact answers please.
I have a compiled program (no source code) that takes in command line arguments. There is a correct sequence of a given number of command line arguments that will make the program print out "Success." Given the wrong arguments it will print out "Failure."
One thing that is confusing me is that the instructions mention two system tools (doesn't name them) which will help in figuring out the correct arguments. The only tool I'm familiar with (unless I'm overlooking something) is GDB so I believe I am missing a critical component of this challenge.
The challenge is to figure out the correct arguments. So far I've run the program in GDB and set a breakpoint at main but I really don't know where to go from there. Any pro tips?
Are you sure you have to debug it? It would be easier to disassemble it. When you disassemble it look for cmp
There exists not only tools to decompile X86 binaries to Assembler code listings, but also some which attempt to show a more high level or readable listing. Try googling and see what you find. I'd be specific, but then, that would be counterproductive if your job is to learn some reverse engineering skills.
It is possible that the code is something like this: If Arg(1)='FOO' then print "Success". So you might not need to disassemble at all. Instead you only might need to find a tool which dumps out all strings in the executable that look like sequences of ASCII characters. If the sequence you are supposed to input is not in the set of characters easily input from the keyboard, there exist many utilities that will do this. If the program has been very carefully constructed, the author won't have left "FOO" if that was the "password" in plain sight, but will have tried to obscure it somewhat.
Personally I would start with an ltrace of the program with any arbitrary set of arguments. I'd then use the strings command and guess from that what some of the hidden argument literals might be. (Let's assume, for the moment, that the professor hasn't encrypted or obfuscated the strings and that they appear in the binary as literals). Then try again with one or two (or the requisite number, if number).
If you're lucky the program was compiled and provided to you without running strip. In that case you might have the symbol table to help. Then you could try single stepping through the program (read the gdb manuals). It might be tedious but there are ways to set a breakpoint and tell the debugger to run through some function call (such as any from the standard libraries) and stop upon return. Doing this repeatedly (identify where it's calling into standard or external libraries, set a breakpoint for the next instruction after the return, let gdb run the process through the call, and then inspect what the code is doing besides that.
Coupled with the ltrace it should be fairly easy to see the sequencing of the strcmp() (or similar) calls. As you see the string against which your input is being compared you can break out of the whole process and re-invoke the gdb and the program with that one argument, trace through 'til the next one and so on. Or you might learn some more advanced gdb tricks and actually modify your argument vector and restart main() from scratch.
It actually sounds like fun and I might have my wife whip up a simple binary for me to try this on. It might also create a little program to generate binaries of this sort. I'm thinking of a little #INCLUDE in the sources which provides the "passphrase" of arguments, and a make file that selects three to five words from /usr/dict/words, generates that #INCLUDE file from a template, then compiles the binary using that sequence.
I am writing a compiler written in OCaml. Sometimes when there is an error of execution, it shows the line of error, but it does not show the context, for instance, how the function is called, with which values...
In order to help debugging, does anyone know a way to show the steps of execution till the error with real value of the relevant variables?
By the way, I am using Emacs as editor.
Ocaml is compiled. You seem to be used to interpreted languages, where the run-time system has access to the full program source code. With a compiled program, the run-time system doesn't have access to much information. For example, variable names disappear at compile time, and nothing will keep track of the arguments passed to every function except as needed for the normal program execution (doing that would incur a lot of overhead).
If you compile your program with debugging symbols (pass the -g option to the compiler), you can get a stack trace if your program dies of an uncaught exception. You'll get function names and some program locations, but not detailed memory contents. Compiling with debugging information results in a bigger executable, but doesn't change the run-time performance. You need to set the OCAMLRUNPARAM environment variable to contain b when running the program.
ocamlc -g -o foo foo.ml
export OCAMLRUNPARAM=b
./foo
If you want more information, you need to run your program inside a debugger.
I would like the command gdb on program X to instead switch to an existing debugging session of X if it already exists instead of signalling an error "This program is already being debugged" in gud-common-init.
I believe this is important as it makes the behaviour of gdb harmonize with the standard behaviour of most other Emacs interactions such as, find-file, switch-to-buffer etc, thus creating less confusion to the user.
So far I have modified the line containing
(error "This program is already being debugged"))
to instead do
(message "This program is already being debugged")
to at least prevent the error from arising. However, the function gdb does some extra initializations that should not be needed that causes some unnecessary delays. Is this a todo item or have I missed some gud/gdb-function that does this already?
Many thanks in advance,
Per Nordlöw
You can always rename-buffer. This is how I can run multiple gdb sessions on the same executable. It is not automatic but it is an effective work around.
For example if my executable is called pump, then upon running gdb, a buffer named *gud-pump* will be generated which represents the gdb session. From this buffer do meta-x rename-buffer *gud-pump1*
Then invoke gdb again and you will have two GUD sessions, one *gud-pump* and *gud-pump1*. The sessions are separate and should not interfere (although they can interact) with each other.
I'm trying to use gdb in postmortem mode with the core dump of a crashed process. I can get a stack trace, but instead of showing me the actual location in the offending function, gdb shows me the line number of a two-line inlined function that the offending function calls.
The inlined function is called many, many places; how do I find which call triggered the crash? How do I find the code immediately around the inlined function?
Go to the stack frame in question, print the instruction point (e.g. p $rip),
then use it to look it up manually with e.g. "addr2line -e -i 0x84564756".
This doesn't scale, but at least it works.
I assume that the "many many calls to the inlined function" are all happening from within a single "offending function" (otherwise your question doesn't make sense to me).
Your best bet is to note the IP address of the crash point in GDB, then use "objdump -dS ./a.out" and find that IP in the output.
You can try setting OPTIMIZE to NO (eg. setenv OPTIMIZE NO) and rebuild the project: this tells compiler not optimize code, hence it may not inline function calls.