3 ms·

These are all useful, and I would even say fundamental, commands. But, as such, these are also very basic commands, not tricks. If you're looking for something

These are all useful, and I would even say fundamental, commands. But, as such, these are also very basic commands, not tricks. If you're looking for something more advanced, you'll be disappointed. I strongly suggest to anyone using gdb to just read the manual [0]. Or at least skim it quickly and find a dozen of such useful "tricks" in as many minutes. The time gained in debugging later is well worth knowing and mastering your tools. Here's a quick summary of the article, most of this stuff is covered in the first few chapters of the manual : 1. conditional breakpoints, yes, they exist 2. execute commands each time a breakpoint is hit, yes, that's possible 3. pass commands to the program directly from gdb's command line 4. define source directories 5. debug macros with the right compile options 6. you can use the results of commands, and even define variables ! 7. you can access cpu registers 8. you can even examine memory [0] http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz : it looks big but a lot of it is annexes at the end, or how to extend GDB with your own scripts, which can be interesting but can easily be skipped in the beginning. The important chapters to begin with would be : - Getting in and out of gdb - gdb commands - Running programs under gdb - Stopping and continuing <-- breakpoints 101, learn about conditional breakpoints (you can also set the conditions after setting the breakpoint), hardware breakpoints on data (called watchpoints in gdb), how to skip quickly (to end of function|a whole file|...), etc. - Examining the stack - Examining source files - Examining data <-- very important, discover the joy of artifical arrays, casting with @ or {type}, configuring the display etc. - Altering execution

sitkack 12y ago
I found constructing small problems and solving them with GDB when not under pressure greatly expanded my working knowledge. Trying to learn GDB while attempting to solve a time critical production bug is not possible for me.
- voltagex_ 12y ago
  Have you got any of those problems written down or any pointers for creating them? That sounds like fantastic material for a tutorial.
  - sitkack 12y ago
    on mobile ... play with a running program like wget, step through nginx request, debug a python script. wget is by far the richest playground. setup a site on local host for wget to spider, modify bandwidth, wait time and kinds of links to follow.
- cataflam 12y ago
  I can relate to that. When you are not under critical pressure is a great time to print the manual, sit back and try new stuff on some minor bug somewhere. I actually developed most of my debugging skill when younger, by reverse engineering other programs and games. And after reversing foreign code from the binaries, debugging with the source code seems comfortable. It is also great to get more familiar with the inner working of the processor and to understand what instructions different languages and compilers produce. It was not with gdb, but debugging is debugging. Switching debugger when you've known a few is like learning a new programming language when you know others, but much easier. You just need to find the new syntax, they're mostly similar. One thing you learn quickly when REing is also not to jump head first in the debugger. Sometimes your problem can be solved easier using a different route, and that applies to debugging as well. A good read of a promising part of the source code or a well placed debug trace can sometimes be much faster. For others who want to learn, there are plenty of reverse engineering tutorials you can find with a simple search. I have a particular place in my heart for fravia's (RIP) old website (should still be mirrored by woodmann [0]). It's a bit dated and there may be a better place to start now but it certainly covers some basics. [0] http://www.woodmann.com/fravia/ http://www.woodmann.com/fravia/ You can check out http://www.woodmann.com/forum/content.php http://www.woodmann.com/forum/content.php for more modern stuff while you're there

sitkack 12y ago

I found constructing small problems and solving them with GDB when not under pressure greatly expanded my working knowledge. Trying to learn GDB while attempting to solve a time critical production bug is not possible for me.

voltagex_ 12y ago
Have you got any of those problems written down or any pointers for creating them? That sounds like fantastic material for a tutorial.
- sitkack 12y ago
  on mobile ... play with a running program like wget, step through nginx request, debug a python script. wget is by far the richest playground. setup a site on local host for wget to spider, modify bandwidth, wait time and kinds of links to follow.
cataflam 12y ago
I can relate to that. When you are not under critical pressure is a great time to print the manual, sit back and try new stuff on some minor bug somewhere. I actually developed most of my debugging skill when younger, by reverse engineering other programs and games. And after reversing foreign code from the binaries, debugging with the source code seems comfortable. It is also great to get more familiar with the inner working of the processor and to understand what instructions different languages and compilers produce. It was not with gdb, but debugging is debugging. Switching debugger when you've known a few is like learning a new programming language when you know others, but much easier. You just need to find the new syntax, they're mostly similar. One thing you learn quickly when REing is also not to jump head first in the debugger. Sometimes your problem can be solved easier using a different route, and that applies to debugging as well. A good read of a promising part of the source code or a well placed debug trace can sometimes be much faster. For others who want to learn, there are plenty of reverse engineering tutorials you can find with a simple search. I have a particular place in my heart for fravia's (RIP) old website (should still be mirrored by woodmann [0]). It's a bit dated and there may be a better place to start now but it certainly covers some basics. [0] http://www.woodmann.com/fravia/ http://www.woodmann.com/fravia/ You can check out http://www.woodmann.com/forum/content.php http://www.woodmann.com/forum/content.php for more modern stuff while you're there