glib generates a macro x_get_instance_private() for type x.
When debugging using gdb, I cannot call macros.
How do I view the instance private data? The function I'm debugging does get the instance private data, but the variable which holds it has been <optimized out>.
You could make use of g_type_class_get_instance_private_offset.
Based on sourcejedi answer, for NMManager (NetworkManager):
(gdb) p *( (NMManagerPrivate *) ((char *) manager
+ g_type_class_get_instance_private_offset(
((GTypeInstance *)manager)->g_class )))
This works when the private is not exactly before the object. Checked on
NMManager where the layout is not standard GObject.
When debugging using gdb, I cannot call macros.
Note that if you compile with -g3, then gcc will put macro bodies into the debug info, and gdb will let you use them in expressions.
That said, gdb only understands the "expression" subset of C -- so if the macro introduces a new scope or does other non-trivial stuff, then it won't work.
Example for GsShell (gnome-software). I have a GObject called object. I discovered by experiment: the private data is stored before the GObject.
(gdb) p *( (*GsShellPrivate) ((char *) object - sizeof(GsShellPrivate)) )
Related
I am doing a postmortem analysis of a crashed program. I am on Linux (Ubuntu 12.04, x86), the code is written in C++. The Program is using some singletons that may contain valuable information. Is it possible to find the pointer to the instance of a singleton if it was created like this:
SingletonType& SingletonType::getInstance(){
static SingletonType* instance = new SingletonType();
return *instance;
}
And if its is possible, how is it done in GDB?
Run gdb with the core file, and run the command
disassemble SingletonType::getInstance
On my test-program I found a mov 0x<addr>, %eax instruction near the end of the method. A print *(*(SingletonType**) <0xaddr>) should print the contents of your singleton structure.
show modules1 should probably tell you the base addresses, and instance, being statically allocated, should be visible in some kind of objdump/nm report. Yeah hairy maths.
The alternative would be to disassemble SingletonType::getInstance() and see what effective address gets loaded in the initialization/return path.
1 Mmm can't find the exact match I was remembering. info sharedlibrary would get you most info.
this is what I do, while inside the core with gdb:
(gdb) info var instance
this will list all the addresses of all the singletons instances, among which you will find the one of SingletonType
0x86aa960 SingletonType::getInstance()::instance
Now that I have the address you can print the your instance' pointed memory:
(gdb) p *((SingletonType*)0x86aa960)
That one surprised me, when doing tab for auto complete for a breakpoint it appeared two options to the same method.
test::TestFoo::SendFoo(short)
test::TestFoo::SendFoo(short)::fooID
On cpp:
bool TestFoo::SendFoo( short x )
{
...
static unsigned int fooID = 0;
Why gdb differs? what's the benefit of using one or another?
Question tagged as C++ to avoid any missunderstanding from C static.
gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
...
SendFoo::fooID and SendFoo are two different kinds of symbols, and I can imagine there will be a difference in the two breakpoints gdb offers you - although I am not very familiar with it:
The line where fooID is defined/initialized will be only hit once in the whole program, so a breakpoint in that line should be hit only once as well. A function level breakpoint should be hit every time the function gets called, so there is a major difference.
AFAIK the function scope static means the same for both C and C++ - a variable that is shared between all calls of that function and initialized the first time the function gets called.
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.
What I want is a mix of what can be obtained by a static code analysis like Doxygen and the stackframe you can see when using GDB. I know which problematic function I'm debugging and I want to see the neighbourhood of the function calls that guided the execution to this function call. For instance, running a simple HelloWorld! would output something like:
main:
Greeter::Greeter()
Greeter::printHello()
Greeter::printWorld()
denoting that from the main function, the constructor was called and then the printHello and printWorld functions where called. Notice that in GDB if I break at printWorld I won't be able to see in the stackframe that printHello was called.
Any ideas about how to trace function calls without going through the pain of inserting log messages in a myriad of source files?
Thanks!!
The -finstrument-functions option to gcc instructs the compiler to call a user-provided profiling function at every function entry and exit.
You could use this to write a function that just logs every function entry and exit.
From reading the question I understand that you want a list of all relevant functions executed in order as they're executed.
Unfortunately there is no application to generate this list automatically, but there are helper macros to save you a lot of time. Define a single macro called LOGFUNCTION or whatever you want and define it as:
#define LOGFUNCTION printf("In %s (%s:%d)\n", __PRETTY_FUNCTION__, __FILE__, __LINE__);
Now you do have to paste the line LOGFUNCTION wherever you want a trace to be added.
wherever you see fit.
see http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html and http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
GDB features a stack trace, it does what you ask for.
What he wants is to obtain tha info (for example, backtrace from gdb) but printed in a 'nicer' format than gdb do.
I think you can't. I mean, maybe there is some type of app that trace your application and do something like that, but I never hear about something like that.
The best thing you can do is use GDB, maybe create some type of bash script that use gdb to obtain the info and print it out in the way you like.
Of course, your application MUST be compiled with debug symbols (-g param to gcc).
I'm not entirely sure what the problem is with gdb's backtrace, but maybe a profiler is closer to what you want? For example, using valgrind:
valgrind --tool cachegrind ./myprogram
kcachegrind callgrind.out.NNNN
Have you tried to use gprof to generate a call graph? You can also convert gprof output to something easier on the eye with gprof2dot for example.
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.