I'm reverse engineering a program using gdb and I'm getting confused in all the addresses I enter to various commands. Is there a way to create (and store) a custom variable so that I could say x/i my_addr_name instead of x/i 0xdeadbeef?
gdb has user-definable convenience variables to hold various values.
(gdb) set $my_addr_name=$pc
(gdb) x/i $my_addr_name
=> 0x400c7d <main+390>: lea -0xa0(%rbp),%rax
(gdb) ptype $my_addr_name
type = void (*)()
Convenience variable have a type, and the print command will make use of that, but the x command uses explicit or default formats and doesn't take the type of the expression into account.
could I have x/i 0xdeadbeff say my_addr_name+16
I don't think so, unless some additional C or python code is written. gdb's C source code has a build_address_symbolic function, which looks through the symbol tables to find the symbol nearest to an address. Short of creating a custom symbol table, then loading it with the add-symbol-file command, or writing a python extension to implement an alternative to the x command, I don't think such a customization is possible, currently.
Related
Sometimes there is a function in my binary that I'm sure hasn't been optimized away, because it's called by another function:
(gdb) disassemble 'k3::(anonymous namespace)::BM_AwaitLongReadyChain(testing::benchmark::State&)'
Dump of assembler code for function k3::(anonymous namespace)::BM_AwaitLongReadyChain(testing::benchmark::State&):
[...]
0x00000000003a416d <+45>: call 0x3ad0e0 <k3::(anonymous namespace)::RecursivelyAwait<k3::(anonymous namespace)::Immediate17>(unsigned long, k3::(anonymous namespace)::Immediate17&&)>
End of assembler dump.
But if I ask GDB to disassemble it using the very same name that it refers to the function with, it claims the function doesn't exist:
(gdb) disassemble 'k3::(anonymous namespace)::RecursivelyAwait<k3::(anonymous namespace)::Immediate17>(unsigned long, k3::(anonymous namespace)::Immediate17&&)'
No symbol "k3::(anonymous namespace)::RecursivelyAwait<k3::(anonymous namespace)::Immediate17>(unsigned long, k3::(anonymous namespace)::Immediate17&&)" in current context.
However, if I disassemble it using its address, it works fine:
(gdb) disassemble 0x3ad0e0
Dump of assembler code for function k3::(anonymous namespace)::RecursivelyAwait<k3::(anonymous namespace)::Immediate17>(unsigned long, k3::(anonymous namespace)::Immediate17&&):
0x00000000003ad0e0 <+0>: push rbp
[...]
End of assembler dump.
This is terribly inconvenient, because I don't know the address a priori—I have to go disassemble a caller just to find the address of the callee. It's really cumbersome.
How can I get GDB to disassemble this function by name? I assume this is some issue with name mangling/canonicalization, probably around the rvalue references and/or anonymous namespaces, but I can't figure out what exactly is going on. I'm using GDB 10.0-gg5.
But if I ask GDB to disassemble it using the very same name that it refers to the function with, it claims the function doesn't exist
There are many possible mangling schemes; the relationship between mangled and unmangled names is not 1:1.
The parser built into GCC which turns foo::bar(int) into something which can be used to lookup the symbol in the symbol table may have bugs.
This is terribly inconvenient, because I don't know the address a priori—I have to go disassemble a caller just to find the address of the callee.
If the called function is already on the stack (i.e. part of active call chain), you can easily disassemble it via disas $any_address_in_fn -- you don't need to give GDB the starting address. So you could do e.g. frame 5 followed by disas $pc -- GDB will find enclosing function in the symbol table and disassemble it in its entirety.
Another option is to get the address from file:line info: info line foo.cc:123 followed by disas $addr_given_by_previous_command.
If you know that foo::bar() exists somewhere, but don't know its source location, another option is to set a breakpoint on it via e.g. rbreak 'foo::bar'. This will tell you the address where the breakpoint was set, and you can disassemble that address.
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! :)
I'm working with a C++ library. The library uses several namespaces. When debugging, I have to prefix every symbol name with the namespace prefix. It causes a lot of extra work and typing.
C++ has the using namespace X concept to make symbols available with more ease (lots of hand waiving). I'm looking for similar in GDB. For example, instead of b MyLibNamespace::Foo::bar, I want to b Foo::bar.
GDB does not appear to have help related to namespaces, but I'm probably doing something wrong:
(gdb) help namespace
Undefined command: "namespace". Try "help".
(gdb) namespace help
Undefined command: "namespace". Try "help".
How do I tell GDB to use a namespace prefix so I don't have to provide it for every symbol name?
How do I tell GDB to use a namespace prefix so I don't have to provide it for every symbol name?
There doesn't appear to be any such support in current GDB (as of 2017-08-13).
You can probably implement it using Python scripting to define a new command. Documentation.
Beware, this is entirely non-trivial proposition.
How do I tell GDB to use a namespace prefix so I don't have to provide
it for every symbol name?
You might consider a work-around...
I have (on occasion) added one or more (C++) functions to my class definitions file. (.cc), but they are not part of the class(s).
They are not part of the application, and are harmlessly removed when you are done with them.
They generally 'dump' info (with names d1(), d2(), etc.)
But they can also do practically any thing useful for your debugging effort, Usually, it is not the case that you thought of this specific test effort ahead of time.
So, your edit/compile/link iteration is simply: stop gdb, open the file, add a useful function, line, and resume gdb. Keep this 'diagnostic' code simple. Hopefully the result is ultimately time saving.
I can find no examples (in my files) at the moment. I suppose I discard these functions quickly once I've overcome a particular challenge.
Anyway ... this demo worked just a few minutes ago ...
When working in gdb near my class Foo_t, part of namespace DTB, etc. the d1 I've created knows how to access a particular instance of Foo_t (in some convenient way), and, can easily dump the current state of the instance using a Foo method to do so. Perhaps d1 can look like this:
void d1() { objDer.f("xxx"); } // a derived instance,
// the class has a long complex name.
Now, in gdb, run to a breakpoint somewhere when that instance exists, and is initialized, and use gdb print command to run d1 ...
(gdb) p d1()
that is a short gdb command to get at the instance and run a method.
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)
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.