Currently GDB prints only trivial arguments in backtrace (only scalars); something like below
(gdb) bt 1
(gdb) function1(this=this#entry=0xfff6c20, x1=-1, x2=3, x3=...
and so on. x3 here could be a array/STL vector and by default GDB does not display it.
I am using lot of STL vectors and Blitz arrays in my code.
I have routines in .gdbinit file to display STL vectors, and subroutines in c++ where I can make use of call functionality in GDB, which can display the array contents. To manually print the vector/array contents, I would use
(gdb) printVector vector_name -> this is a routine in my .gdbinit
(gdb) call printBlitzArray(array_name) -> this is a routine inside my executable itself.
How can we make GDB display the non trivial arguments of a function like below.
void myFunc(int x1, int x2, std::vector<int> x3, blitz::Array<bool, 1> x4)
I got to know using set print frame-arguments all can display some of the non trivial arguments.
But how to really print arguments where GDB may not have a native support for printing them.
The intent is to automatically print all the arguments at the start of the function (atleast whichever we can).
I can write a GDB script and add prints individually for each vector/array, but doing this for every function would be very time consuming, since I have a large number of functions. This would help a lot to accelerate my debug.
Any suggestion is highly appreciated.
Thanks a lot in advance !
I've just tested this on my own machine, use -rdynamic when compiling.
-rdynamic flag basically makes an additional copy for all of your symbols (not just dynamic symbols or externally dependant) to the dynamic symbol table of your executable, thus allowing them to be loaded into your memory during runtime of the program and not simply used by your linker as some metadata, this provides any backtracing mechanism the fully name-mangled symbol and allowing it to be parsed into your original function (without the actual names of function parameters, just types), hope this helps! :)
Related
Looking through a core file(generated by C code) with gdb, I am unable to understand one particular thing between these 2 frames
#2 increment_counter (nsteps=2, steps=0x7f3fbad26790) at gconv_db.c:393
#3 find_derivation (...) at gconv_db.c:426
This code is from open source glibc where find_derivation calls increment_counter as:
result = increment_counter (*handle, *nsteps);
The *handle and steps are of the same type and increment_counter function is defined as static
Why does gdb show that the 2 parameters have different order ?
I am pretty sure that glibc was taken as is without modification
Why does gdb show that the 2 parameters have different order ?
GDB doesn't know anything about the source (except possibly where on disk it was located at build time).
It is able to display parameters (and their values) because the compiler told it (by embedding debug info into the object file) what parameters are, in what order they appear, their types, and how to compute their value.
So why would a compiler re-order function arguments?
The function is static, so it can't be called from outside of the current translation unit. Thus the compiler is free to re-order the parameters, so long as it also re-orders the arguments at every call site.
Still, why would it do that? General answer: optimization (compiler found it more convenient to pass them in this order). Detailed answer would require digging into GCC (or whatever compiler was used to build this code) source.
I have some legacy C++ code that hasn't been maintained in years. I'm trying to learn how it functions at the moment. It takes .xml input and should spit out an output text file. Two different .xml input files take vastly different amounts of time to process, and one of them behaves properly, the other doesn't. They begin the same though. I'd like to output log files of the function calls made when I execute the code with the two different inputs and diff these logs against one another to see where they begin to diverge. I can't just interrupt the code right at the first line of main() and step my way through the control flow in gdb. It's taking way too long. Ideally, I'd like to find a way to do something like
gdb --args old_exec inp1.xml -step >log1.txt
gdb --args old_exec inp2.xml -step >log2.txt
diff log1.txt log2.txt
The "-step" flag isn't real, of course, but maybe some way to tell it to log all the steps does exist. Any thoughts? Thanks!
The GCC compiler has a flag, -finstrument-functions, which causes your functions to call specific functions on entry and exit; you can use this to track your code flow. With this flag in use, you will need to provide the following functions:
void __cyg_profile_func_enter (void *this_fn, void *call_site);
void __cyg_profile_func_exit (void *this_fn, void *call_site);
and keep in mind that when you compile those functions, they must not be compiled with the intrumentation flag!
You can use addr2line to convert pointers to file/function/line numbers. It would generally be better to record the raw pointers at run-time, and perform post mortem address conversion.
See http://balau82.wordpress.com/2010/10/06/trace-and-profile-function-calls-with-gcc/ for more details.
Is there a way, maybe using nm, or gdb, that will let me create a list of all the object types that an executable contains?
To clarify, I have the source code. I need a method for figuring out all the class/struct sizes that are used at runtime. So this is probably a two part problem:
create a list of all classes/structs
use sizeof() on each of the items on the list, in gdb.
"Types" aren't a property of machine code. They're a property of a high-level, abstract language, which is compiled into machine code. Unless the compiler makes specific arrangements for you to recover information about the source program, type information generally doesn't exist at all.
http://www.hex-rays.com/products/ida/index.shtml : DeCompiler for C++
You will usually not get good C++ out of a binary unless you compiled in debugging information. Prepare to spend a lot of manual labor reversing the code.
If you didn't strip the binaries there is some hope as IDA Pro can produce C-alike code for you to work with.
It's easy to get a list of types from gdb. You just want info types and then ptype if you want to drill down into the type (limiting it to types matching a string just to keep this small):
(gdb) info types Q
All types matching regular expression "Q":
File foo.cpp:
Qq;
(gdb) ptype Qq
type = class Qq {
private:
int qx;
public:
Qq(int);
std::__cxx11::string something(std::__cxx11::list<int, std::allocator<int> >);
int getQ(void);
}
And sizeof tells you how big the structure is (of course, it's the structure itself, so this may or may not be all that useful):
(gdb) p sizeof(Qq)
$1 = 4
(gdb)
You'll probably want to run gdb in a script and parse the output somehow.
I want to dump a backtrace from a C++ program in Linux in a similar format as it is done in gdb. I tried to use the backtrace() and backtrace_symbols() functions for this purpose. These returned function names and offsets. I can use the __cxa_demangle() function to get a readable function name.
Is there any way to get the file/line positions too, as it is done by gdb?
How it's better to invoke gdb from program to print its stacktrace?`
Methode #4, shows a way to get filename and line. But uses a extern program..
I have a 3rd party source code that I have to investigate. I want to see in what order the functions are called but I don't want to waste my time typing:
printf("Entered into %s", __FUNCTION__)
and
printf("Exited from %s", __FUNCTION__)
for each function, nor do I want to touch any source file.
Do you have any suggestions? Is there a compiler flag that automagically does this for me?
Clarifications to the comments:
I will cross-compile the source to run it on ARM.
I will compile it with gcc.
I don't want to analyze the static code. I want to trace the runtime. So doxygen will not make my life easier.
I have the source and I can compile it.
I don't want to use Aspect Oriented Programming.
EDIT:
I found that 'frame' command in the gdb prompt prints the current frame (or, function name, you could say) at that point in time. Perhaps, it is possible (using gdb scripts) to call 'frame' command everytime a function is called. What do you think?
Besides the usual debugger and aspect-oriented programming techniques, you can also inject your own instrumentation functions using gcc's -finstrument-functions command line options. You'll have to implement your own __cyg_profile_func_enter() and __cyg_profile_func_exit() functions (declare these as extern "C" in C++).
They provide a means to track what function was called from where. However, the interface is a bit difficult to use since the address of the function being called and its call site are passed instead of a function name, for example. You could log the addresses, and then pull the corresponding names from the symbol table using something like objdump --syms or nm, assuming of course the symbols haven't been stripped from the binaries in question.
It may just be easier to use gdb. YMMV. :)
You said "nor do I want to touch any source file"... fair game if you let a script do it for you?
Run this on all your .cpp files
sed 's/^{/{ENTRY/'
So that it transforms them into this:
void foo()
{ENTRY
// code here
}
Put this in a header that can be #included by every unit:
#define ENTRY EntryRaiiObject obj ## __LINE__ (__FUNCTION__);
struct EntryRaiiObject {
EntryRaiiObject(const char *f) : f_(f) { printf("Entered into %s", f_); }
~EntryRaiiObject() { printf("Exited from %s", f_); }
const char *f_;
};
You may have to get fancier with the sed script. You can also put the ENTRY macro anywhere else you want to probe, like some deeply nested inner scope of a function.
Use /Gh (Enable _penter Hook Function) and /GH (Enable _pexit Hook Function) compiler switches (if you can compile the sources ofcourse)
NOTE: you won't be able to use those macro's. See here ("you will need to get the function address (in EIP register) and compare it against addresses in the map file that can be generated by the linker (assuming no rebasing has occurred). It'll be very slow though.")
If you're using gcc, the magic compiler flag is -g. Compile with debugging symbols, run the program under gdb, and generate stack traces. You could also use ptrace, but it's probably a lot easier to just use gdb.
Agree with William, use gdb to see the run time flow.
There are some static code analyzer which can tell which functions call which and can give you some call flow graph. One tool is "Understand C++" (support C/C++) but thats not free i guess. But you can find similar tools.