3 ms·

In the past working on a large c++ codebase I've tried using a debugger to get an understanding on how a function gets called. Even the debugger fails when you

In the past working on a large c++ codebase I've tried using a debugger to get an understanding on how a function gets called. Even the debugger fails when you come across indirect calls. Also in gdb multiple threads make it easy to miss something when stepping through code.

realharo 10y ago
Visual Studio's debugger has some really nice features and interface for dealing with multi-threaded code https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus-Plus-Debugging-Tips-and-Tricks#time=19m42s https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus...
barrkel 10y ago
Debuggers aren't always the best tool for figuring out control flow - accidentally step over something and you can miss it - but they are useful to explore the map of data in memory. Some debuggers let you expand out the map hierarchically, others use separate windows (e.g. the old Borland IDE Debug Inspector windows). For exploring control flow, an instrumenting profiler is really useful, if you can easily isolate a representative code run.
bigger_cheese 10y ago
A few years ago now at my work I wanted to get my head around how our large c++ code base worked I used a tool called Doxygen it was pretty useful for reading and visualizing the source code. It output html pages and could generate dependency graphs etc automatically would show you which file a function came from let you browse by class or by individual source files etc. You could easily see every file a class was referenced in etc. Downside was it took a long time (many hours) to scan the entire codebase.
Asooka 10y ago
I would strongly suggest you check out rr - Mozilla's Record and Replay framework https://github.com/mozilla/rr https://github.com/mozilla/rr . Don't let the name confuse you - it's not specific at all to Firefox. It can record a process's execution and replay it in gdb, and lets you step and continue backwards. This last point is super powerful - let's say you see that some variable has an unexpected value. You can set a watchpoint on it, then reverse-continue and gdb will stop at the point it was changed. It has been invaluable in finding some tricky bugs. Apart from that, you can also use it to explore the execution of a program, since you can freely step backwards and forwards in time. You also get a deterministic thread execution sequence each time. That might be either good or bad, depending on what you want.

realharo 10y ago

Visual Studio's debugger has some really nice features and interface for dealing with multi-threaded code https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus-Plus-Debugging-Tips-and-Tricks#time=19m42s https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/C-Plus...

barrkel 10y ago

Debuggers aren't always the best tool for figuring out control flow - accidentally step over something and you can miss it - but they are useful to explore the map of data in memory. Some debuggers let you expand out the map hierarchically, others use separate windows (e.g. the old Borland IDE Debug Inspector windows). For exploring control flow, an instrumenting profiler is really useful, if you can easily isolate a representative code run.

bigger_cheese 10y ago

A few years ago now at my work I wanted to get my head around how our large c++ code base worked I used a tool called Doxygen it was pretty useful for reading and visualizing the source code. It output html pages and could generate dependency graphs etc automatically would show you which file a function came from let you browse by class or by individual source files etc. You could easily see every file a class was referenced in etc. Downside was it took a long time (many hours) to scan the entire codebase.

Asooka 10y ago

I would strongly suggest you check out rr - Mozilla's Record and Replay framework https://github.com/mozilla/rr https://github.com/mozilla/rr . Don't let the name confuse you - it's not specific at all to Firefox. It can record a process's execution and replay it in gdb, and lets you step and continue backwards. This last point is super powerful - let's say you see that some variable has an unexpected value. You can set a watchpoint on it, then reverse-continue and gdb will stop at the point it was changed. It has been invaluable in finding some tricky bugs. Apart from that, you can also use it to explore the execution of a program, since you can freely step backwards and forwards in time. You also get a deterministic thread execution sequence each time. That might be either good or bad, depending on what you want.