Posts Tagged gdb
Three GDB tricks for the masses
Posted by Alessandro Pignotti in Coding tricks on May 8, 2009
The GNU Debugger is a very powerful and fearsome beast. It seems that I’ve found a couple of useful tricks which are not popular as they should.
- The watch command: any script kiddie knows about breakpoints. Watchpoints are based on the same concept applied to not to code, but to data memory. You can set a watchpoint on a variable using the following syntax:
watch var.
It is also possible to watch a specific memory address with the syntax:watch *0xdeadbeaf
. A watchpoint triggers when the contents of the memory location changes, so they are useful when trying to find out when a variable is modified. (remember that in C++ you should always use private and protected sections to stop variables from being accessed/modified outside the expected code flow). It is also possible to set read watchpoints using the rwatch command, which triggers when the location is accessed. This feature is mainly useful when reverse engineering compiled code, to find out which code path make use/are influenced by a certain variable/memory location. The major drawback of watchpoints is that common hardware support only a few of them. When gdb runs out of hardware watchpoints it resorts to software emulation, which is very slow, and not possible at all for the read ones. This also means that putting watchpoints on big structures and classes is highly discorauged. - set print object: If you’ve ever made extensive use of polymorphic classes or otherwise complex class hierarchies, you will find this setting very useful. The print command, when printing pointers of base classes, will take look at the virtual table to find out the actual object type, and print it beside the address. Moreover when dereferencing pointers it will print the full object contents, not only the base class members.
- info threads command: When you face a deadlock in your multithreaded code, the first step to understand the problem is to find out which threads are blocked. The deadlock is often not easily reproducible, so should at first attach gdb the the process using the attach <pid> command, the typing info threads you will get for each thread the function name where it is currently stopped. Threads involved in a deadlock conditions are usually stopped in sem_wait or similar semaphore related functions
Well... I guess I’m using gdb way too much, maybe I’m not a good programmer
Fun with ptrace: system emulation
Posted by Alessandro Pignotti in Coding tricks on May 4, 2009
The more I explore the interfaces deeply hidden in the linux kernel, the more a new world of opportunity opens. Today, while taking a look at the ptrace API, I found out the PTRACE_SYSEMU option.
But what is ptrace? It’s a kernel interface to check and manipulate the information that crosses the user space-kernel space frontier. Its main... principal... only user is gdb usually. The PTRACE_SYSEMU option is quite peculiar, it was implemented mainly for the user mode linux project. It allows not only to monitor the system calls invoked by a process, but also to replace the system call sematics.
So... how could this be useful? For example to experiment with different auditing/sandboxing strategies, or to build compatility layers at the system call level... but who knows what kind of funny things could be done!